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