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