No, it's different and hasn't been made public yet. Hopefully Adobe can release it along with Falcon.
- Gordon -----Original Message----- From: omup...@gmail.com [mailto:omup...@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 <gosm...@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:jus...@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 >
