Speaking as the person who has written the most complete spec for MXML (at far
as I know) -- although I'm not currently as an active contributor to Apache
Flex -- this use of $ in the language strikes me as rather arbitrary. Other
MXML compiler directives start with @, such as @Embed, @Resource, and @{...}.
BTW, I see the latter as a poor choice; it should have been something like
@TwoWay{...} for consistency with the others.
I suggest @Once.
- Gordon
-----Original Message-----
From: Justin Mclean [mailto:[email protected]]
Sent: Tuesday, April 24, 2012 10:04 AM
To: [email protected]
Subject: Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue
initializer
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
