incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Om <bigosma...@gmail.com>
Subject MXML specs (Was: Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer)
Date Tue, 24 Apr 2012 18:44:00 GMT
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message