flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Ent <p...@adobe.com.INVALID>
Subject Re: [2/2] git commit: [flex-asjs] [refs/heads/release0.8.0] - fix event types for valuechange. Otherwise Binding would break. Events are global and should be compatible for any given event type
Date Wed, 07 Jun 2017 14:03:56 GMT
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

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.


On 6/7/17, 1:27 AM, "Justin Mclean" <justin@classsoftware.com> wrote:

>> I agree that there could be a even smaller bead that doesn't track
>> 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?

View raw message