Is it possible to support a constant directive using this patch immediately
while we work out the details for the Once directive?
For example, in these examples you would want to have the constant value
but don't want to have the binding overhead:
<s:Label text="The {Event.CLICK} event example" />
<EventHandler eventName="{MyEvents.MENU_CLICK}" >
Or is that already happening with constants?
On Tue, Apr 24, 2012 at 12:28 PM, 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
>
