I don't think PAYG is always obvious and I continue to struggle with the question. Some examples:
a. Anything that can be expressed as a style probably does not need a bead, unless the style is not native to the platform. Border and backgroundColor are good examples. These are built into HTML, but not the Flash Player. So the border and background styles are implemented as beads but they are only available on the Flash Player platform. Width, height, x, y, etc. are also styles in HTML but properties in Flash, so they don't need beads either. Plus they are pretty fundamental to UI systems. b. Completeness also gives me pangs. You would think that a slider's basic properties of a minimum value, maximum value, and a current value would not need to be questioned. And that's true, as properties they are necessary to define a slider. But should a slider emit an event whenever its min, max, or value changes? Many apps will just go get the current value when they need it. The slider's mouse controller observes the dynamic changes in the thumb position and emits an event for each movement - but not everyone needs that so such a controller could be optional, but without a controller, you can't actually change the thumb with the mouse so you need the controller regardless, but do you need to emit the event when the thumb is being moved? c. When you do have to have something, like a slider mouse controller, to make the component work at its basic level, do you make an option as to whether or not to emit the event or do you have one controller that emits events as the thumb moves and one controller that does not emit the event? Is one controller a subclass of the other or a duplicate version? d. Its often difficult to tell if something should be present just because it always has been present (in Flex). When you have a set of properties and events, we need to ask if those are essential to making the component work. Or rather, what is the component's default behavior. For a text input component, the default because is accepting keyboard input, without filtering. Making it a secure input with a mask, is extra work/behavior and thus becomes a bead. Beads enhance and augment the default behavior as a rule of thumb. PAYG for me, raises lots of questions about programming practices and patterns. Do you make it easier on developers by packaging common properties/events/options even if some are not used that often, or do you break them down into many versions? One way to handle this is by looking at the Express project. There, the most commonly used patterns are put together. For instance, data binding is in everything. Or you might have the slider always emit every event it can. The Basic project should be the bare-bones components with lots of options as beads. Then package them into common use cases and put that into another project, like Express, to make it more palatable. I would argue (just a little) that more complex components, like DataGrid, and perhaps even NumericStepper, should be in a project that lives between Basic and Express. This would leave Basic being very, well, basic (label, button, text input, group and container for instance). I hope that helps a little. ‹peter On 6/7/17, 1:27 AM, "Justin Mclean" <jus...@classsoftware.com> wrote: >Hi, > >> I agree that there could be a even smaller bead that doesn't track >>changes >> as you move the thumb. Something to do in the next release, IMO. > >Could be or must be? Again just trying to understand why PAYG wasn¹t >followed in this case. > >Was this just an accidental design omission that no body picked up on it >OR is it sometimes OK to have optional feature code in beads? > >Thanks, >Justin
