Hi,
> There is no guarantee of instantiation order in MXML.
I'm think there's is a defined order for containers and their children to be
instantiated (ie parent before children) and my (limited) understanding was
that children are created in order that they are listed in their container.
Can you explain the issue is here in a bit more detail? Something to do with
repeaters or datagroups?
> That's one of the reasons binding is "slow". It evaluates expressions often
> just in case some
> portion of the expression suddenly becomes available.
For this patch (as supplied) that wouldn't be an issue as the expression would
only be evaluated once right?
I think it would be possible to also force an update (if you were having an
issue) by calling executeBindings? (Not tried)
It's possible to run into timing issues with binding at the moment but it's
fairly rare. I'm not sure this would increase the risk of that.
Binding had been extended in a similar before with 2 way binding:
<mx:TextInput id="t1" text="@{t2.text}"/>
So I feel the syntax makes sense at least.
Perhaps some idea of code size/performance gain would give a clearer idea if
this is a good path to take?
Thanks,
Justin
