Hi Alex,
regarding Binding Events, our experience is that is a bit more hard to work
with them in Royale than in Flex. The main issues we are experiencing are:
1.- In almost all renderers we need to check for null/undefined while in
flex is not needed:
text="{optionPack ? optionPack.description : ''}"
the getter in that renderer is
[Bindable(event="dataChange")]
public function get optionPack():Base7OptionPack
{
return data as Base7OptionPack;
}
migrated from Flex 100% equal
I expect to bind in the following way:
text="{optionPack.description}"
I think our user code will be more PAYG if renderers consider it self the
nulls/undefineds, instead to make users to make consider in almost any
binding.
2.- Level of nested bindings
I think the maximum level of nested properties accessed in a binding is
around 3.
So {foo.woo.zoo} can work but {foo.woo.zoo.noo} will not, while in flex
workd
I think that's the two main issue we see in this real world Apache Royale
project we are immerse now.
Thanks
El mié., 12 dic. 2018 a las 22:54, Alex Harui (<[email protected]>)
escribió:
> I may have missed something, and DispatchChangeOnStartup is a proper bead,
> especially for a first attempt, but theoretically, it shouldn't be needed.
>
> There are different categories of events in Flex and Royale. I'm not sure
> there is a complete list of categories, but ones that pop to mind are:
>
> 1) Low-level interaction events
> 2) Higher-level interaction events
> 3) Binding events.
>
> Things like mouseDown and mouseUp are low-level interaction events. CLICK
> and CHANGE are higher-level interaction events. They imply that some
> series of interactions occurred (CLICK= mouseDown+mouseUp). ITEM_CLICK is
> even higher level, it implies that a click occurred on an ItemRenderer and
> not, say, the scrollbar button in a List. Thus, writing code to dispatch
> CHANGE events outside of controller logic is roughly equivalent to faking
> mouse and keyboard events. Sometimes you gotta do it, but usually it
> implies that something else isn't quite right.
>
> Sometimes it helps to think about whether such a thing was needed in Flex
> and how similar setups worked there. It could be Royale is missing
> something, or something isn't quite right yet. In fact, the Royale binding
> system is trying to be less aggressive and thus have less overhead than
> Flex, but theoretically, the flow of binding events should propagate
> properly to all concerned, so it would be interesting to really understand
> why such a thing was needed. Maybe something is truly only needed at
> startup, but often these things end up being needed elsewhere "later" like
> on state changes or module loads.
>
> The binding system in Royale can handle multiple events. Models are PAYG,
> so some models expect runtime changes and simpler ones don't to save on
> cost. But for models that expect runtime changes (required for any model
> representing asynchronous data loading), the binding events should
> propagate appropriately. Flex used (or maybe overused) VALUE_COMMIT
> events. We can do that, but right now the pattern is to make a unique
> event name. So selectedIndex should dispatch selectedIndexChanged no
> matter how it got changed and that should propagate through other
> bindings. When the dataProvider changes, if that affects the
> selectedIndex, then the model should set the selectedIndex and dispatch
> selectedIndexChanged. There shouldn't be a need to dispatch "change" until
> someone interacts with the component. Differentiating between the two
> usually helps make setup code simpler. You can assign initial values to
> things without reacting everywhere to the change.
>
> Of course, I could be wrong.
> HTH,
> -Alex
>
>
--
Carlos Rovira
http://about.me/carlosrovira
