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

[Peter Ent]

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"  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

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

[Justin Mclean]

Hi,

> I don't think Justin's questions are about the value of PAYG; they rather
> indicate a genuine attempt at understanding the concept.

That’s correct.

Thanks,
Justin

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

[OmPrakash Muppirala]

On Jun 6, 2017 10:42 PM, "Alex Harui"  wrote:

On 6/6/17, 10:27 PM, "Justin Mclean"  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.

I haven't really thought about it.  I'm still just trying to get a release
out.  User expectations are a factor.  Most folks won't need to remove the
PasswordInputBead.  Do most folks want to track the thumb?
>
>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?

Probably one of just many bugs we haven't found or fixed yet.  It is
unfortunate we spend all of this energy trying to convince you of the
value of PAYG instead of finding and fixing these bugs.


Alex,

I don't think Justin's questions are about the value of PAYG; they rather
indicate a genuine attempt at understanding the concept.

I suggest you reset your understanding of his intent and re-read his
emails.  Maybe you will see his line of questioning in a more positive
light.

Thanks,
Om






-Alex

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

[Alex Harui]

On 6/6/17, 10:27 PM, "Justin Mclean"  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.

I haven't really thought about it.  I'm still just trying to get a release
out.  User expectations are a factor.  Most folks won't need to remove the
PasswordInputBead.  Do most folks want to track the thumb?
>
>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?

Probably one of just many bugs we haven't found or fixed yet.  It is
unfortunate we spend all of this energy trying to convince you of the
value of PAYG instead of finding and fixing these bugs.

-Alex

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

[Justin Mclean]

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

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

[Alex Harui]

Actually, I was just trying to eliminate an exception so we can ship a
release.

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.

But I also saw that I hadn't quite implemented the change correctly, so
I've just pushed a better version.

Thanks,
-Alex

On 6/6/17, 5:14 PM, "Justin Mclean"  wrote:

>Hi,
>
>I see you've added code to handle binding / values changes to
>RangeModel.as and RangeModelExtended.as.
>
>Is there any reason the value change code is not in another classes
>called for instance ValueChangeRangeModel? It seem to me that this model
>it trying to do more than one thing i.e. value changes and min/max/step
>changes.
>
>As I user of this I may not be interested minor max changes and only
>interested in value changes so shouldn't that be an optional feature?
>
>I’m just trying to understand why it’s seemingly OK to not follow PAYG
>here.
>
>Thanks,
>Justin

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

[Justin Mclean]

Hi,

I see you've added code to handle binding / values changes to RangeModel.as and 
RangeModelExtended.as. 

Is there any reason the value change code is not in another classes called for 
instance ValueChangeRangeModel? It seem to me that this model it trying to do 
more than one thing i.e. value changes and min/max/step changes.

As I user of this I may not be interested minor max changes and only interested 
in value changes so shouldn't that be an optional feature?

I’m just trying to understand why it’s seemingly OK to not follow PAYG here.

Thanks,
Justin