On 1/9/17, 11:45 PM, "piotrz" <piotrzarzyck...@gmail.com> wrote:
>Sankar,
>
>Yes I know, but I've started to investigate why you need to dispatch any
>events from VO class in order to have workable Binding. - If someone can
>shed some light on this - Is it how we should work with our classes which
>we
>are writing ?
In a chain of bindings (a.b.c) the binding system is supposed to generate
watchers for a, for b, and for c, since you can change c without change a
or b, or change b without change a, or just change a. The binding system
generally has to be careful and watch everything. That's one reason
binding can be slow and heavy when you know you will only change a or c
but not both. That's why in FlexJS binding is implemented as a bead.
Folks can swap in different binding implementations if they need to
optimize for only a changing or something like that.
If you use [Binding] the compiler will generate the code that dispatches
events, but if you use [Bindable("eventName")] then you have to choose the
right time to dispatch the appropriate change event. In ItemRenderers,
for example the "data" property never changes once the renderer is set up
so there is no reason that an item renderer "must" dispatch a change event
in the "data" setter, although I think some renderers do it so folks can
hook it in MXML.
Really, binding is just an automated way of listening for change events.
Which events to "must" listen for depends on your actual scenario, but the
binding beads are going to "aggressively" listen for every possible change
even though sometimes they don't need to.
HTH,
-Alex
