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: MXML specs (Was: Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer)
Date Tue, 24 Apr 2012 22:12:57 GMT
No, it's different and hasn't been made public yet. Hopefully Adobe can release it along with
Falcon.

- Gordon


-----Original Message-----
From: omuppi1@gmail.com [mailto:omuppi1@gmail.com] On Behalf Of Om
Sent: Tuesday, April 24, 2012 11:44 AM
To: flex-dev@incubator.apache.org
Subject: MXML specs (Was: Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue
initializer)

>
> Speaking as the person who has written the most complete spec for MXML 
> (at far as I know)
>

Is that document available somewhere for us to go through?

Or is this what you mean:
http://opensource.adobe.com/wiki/display/flexsdk/MXML+2009 ?

Thanks,
Om


On Tue, Apr 24, 2012 at 10:28 AM, Gordon Smith <gosmith@adobe.com> wrote:

> 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