flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Mclean <jus...@classsoftware.com>
Subject Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Date Tue, 24 Apr 2012 17:04:06 GMT

> 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

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message