The compiler doesn't assume that non-visual components have 'id' and 'document'
properties that it can set. Instead, if a component implements the IMXMLObject
interface, the compiler will call the
function initialized(document:Object, id:String):void;
method so that the component can record the id and the document if it wants to.
So if you want effects to know their id and document, you could make IEffect
extend IMXMLObject and implement initialized().
I think Falcon should implement the same logic regarding 'id' and 'document' as
the old compiler, at least for MXML 2006 and MXML 2009.
- Gordon
-----Original Message-----
From: jude [mailto:flexcapaci...@gmail.com]
Sent: Monday, January 14, 2013 11:48 AM
To: dev@flex.apache.org
Subject: Re: Falcon MXML progress
<fx:Declarations>
<s:Sequence id="mySequence" target="{button1}"/>
</fx:Declarations>
<s:Button id="button1" />
On Mon, Jan 14, 2013 at 12:55 PM, Gordon Smith <gosm...@adobe.com> wrote:
> What is the MXML that produced _KeepTest_Sequence1_i()?
>
> - Gordon
>
> -----Original Message-----
> From: jude [mailto:flexcapaci...@gmail.com]
> Sent: Monday, January 14, 2013 10:33 AM
> To: dev@flex.apache.org
> Subject: Re: Falcon MXML progress
>
> Great. Thanks. I was working on an Effect inspector (shows all the
> effects on a document, play pause, etc and time line) and one of the
> things I noticed with mxmlc was that the ID's were not set on Effects
> and neither were they accessible AFAIK. So what happened was when
> there were multiple effects on a document there was no way to know
> what Sequence did what. Does Falcon add the ID and if not is it
> possible to add it while working on these related MXML items?
>
> In the code below you'll see the generated ActionScript from mxmlc on
> a Effect Sequence and a button. In the button you'll see the ID is
> being set and the document (which also would be useful).
>
> // supporting function definitions for properties, events,
> styles, effects
>
> private function _KeepTest_Sequence1_i() : mx.effects.Sequence
>
> {
>
> var temp : mx.effects.Sequence = new mx.effects.Sequence();
>
> mySequence = temp;
>
> mx.binding.BindingManager.executeBindings(this, "mySequence",
> mySequence);
>
> return temp;
>
> }
>
>
> vs
>
>
>
> private function _KeepTest_Button1_i() : spark.components.Button
>
> {
>
> var temp : spark.components.Button = new spark.components.Button();
>
> temp.id = "button1";
>
> if (!temp.document) temp.document = this;
>
> button1 = temp;
>
> mx.binding.BindingManager.executeBindings(this, "button1", button1);
>
> return temp;
>
> }
>
>
> On Fri, Jan 11, 2013 at 11:30 PM, Rushme Nayak
> <rushme.nay...@gmail.com
> >wrote:
>
> > nice job..thanks
> >
> >
> > <http://mailstat.us/tr/t/dummy>
> > <http://mailstat.us/tr/opt-out?guid=p43e38v20rudihbubft5o>
> >
> >
> > On Sat, Jan 12, 2013 at 4:58 AM, Gordon Smith <gosm...@adobe.com> wrote:
> >
> > > Today I moved to the new repo location, added parser unit tests
> > > for <Component>, <Declarations>, <Definition>, and <Library> tags,
> > > and
> > feature
> > > tests to demonstrate that the <Component> and <Definition> tags work.
> > >
> > > It looks like the old compiler got confused if you put an 'id'
> > > attribute on a tag referring to a <Definition>, but Falcon allows this.
> > >
> > > - Gordon
> > >
> > >
> >
> >
> > --
> > Warm Regards,
> > *Rush-me*
> >
>
