incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Smith <gosm...@adobe.com>
Subject RE: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Date Tue, 24 Apr 2012 17:28:32 GMT
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:justin@classsoftware.com] 
Sent: Tuesday, April 24, 2012 10:04 AM
To: flex-dev@incubator.apache.org
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

Mime
View raw message