FX Ninja #1 : MXML via the "new" constructor
DIGG IT!
10
Comments
Published
Wednesday, May 30, 2007
at
4:06 PM
.
MXML is object oriented. Many do not realize that MXML generates an ActionScript 3 Class at compile-time and thus can be used seamlessly via the "new" constructor. If you want fine grained control of your UI, using MXML class instances can bring another level of fidelity to your applications.
WARNING!!! There is one mistake you can make here that will leave you frustrated. Be careful with naming your MXML components as they generate a similar named ".as" file at compile-time. These generated files are hidden unless you use the "-keep" compiler flag. The error is to use similar names for MXML and AS3 classes. This can lead to a mysterious compiler error and will leave you stuck in the mud!!! You have been warned. :)
Here is a small application that creates 3 MXML class instances using ActionScript and uses the DisplayList API (addChild/removeChild) to swap the UI elements in an out of a panel. The effect is similar to a ViewStack but allows fine grained control over everything including caching the instances at runtime.
Download these two files, compile MXMLViaNew.mxml:
File #1: MXMLViaNew.mxml
File #2: ViewTemplate.mxml
The key here are these lines:
one = new ViewTemplate();
//create an instance of ViewTemplate.MXML via 'new'
one.labelName = "Matt has eaten two Dodgy Prawns!";
//edit the labelName property!
panel.addChild( one );
//add the instance into the panel
See with containers you are really working with the DisplayList in Flash Player 9, Flex simply rides atop all this lower level logic. Once you realize that MXML generates a class and can be used with the "new" contructor, Flex gets 100X more interesting. When I learned this it was a huge breakthrough for me and allowed me to go much deeper into the components and the framework.
I also really like this line of code. It has an elegance that is hard to describe:
if( one ) if( one.parent ) one.parent.removeChild( one );
The line reads like this:
if instance "one" exists and one is attached to the displaylist (has one.parent), remove it through itself ( one.parent.removeChild(one) ).
Pure Ninja AS3 there! HEEEEEE-YAAAAAAAHHHHHH!!!
Dodgy Prawns:
Matt Voerman and I were in Singapore last year for MAX APAC. At dinner in Singapore we has some "Dodgy Prawns" and when Matt asked me for a sample today of MXML via the 'new' constructor, well I integrated the joke. Sorry for the Prawn humor.
cheers,
Ted :)
Sweet post Ted,
I specially love this...
if( one ) if( one.parent ) one.parent.removeChild( one );
That's awesome!! LOL!
Cheers,
Sam
Hi Ted,
is this line
if( one.parent )
the recommended way of checking if an object is on the displaylist?
In any case, this one is remembered because I have lost count of the amount of times I got a null reference error when dealing with add and removeChild.
If the "parent" property is null then it is not on the displaylist. I check for the presence of the instance, then the presence of the parent property.
if (one) if( one.parent) //add/remove
With Flex UIComponents you must remove a component before it is added to another parent. Reparenting with Flex requires removeChild then addChild. With AS3 Projects or Flash CS3, you can reparent by using addChild. The important rule to remember is that one displayObject instance can only be on the displayList in one location, there is only one 'parent', hence the code above.
Regards,
Ted :)
Dodgy Prawns lives on! Woohoo!
Nice work Ted ;-)
Andrew
Adobe (AU)
Hi Ted, me again :-)
Thanks for the info. What do you think of this approach to check if an item is on the displaylist:
if (stage) // add or remove
Anything wrong with that?
Why not:
if ( one && one.parent ) // add/remove
May I post a contra to this nice one-liner:
if( one ) if( one.parent ) one.parent.removeChild( one );
Besides it isn't the best readable solution for some not so talented programmers it isn't the "perfect" one as far as I understand the desired intent:
if( one.parent ) one.parent.removeChild( one );
If there is no one, there won´t be any one.parent ... or reverse ... if there is a one.parent there is also a one for sure.
But anyway:
Favor readable code over clever code!
markus,
"one.parent" member access will throw a runtime exception as one is null.
I prefer working code to code without errors. She is readable and works too!
My 2 cents,
Ted :)
Ouch, you´re right xD ...
But then I prefer
if ( one && one.parent ) // add/remove
anyway :P ;)
Greetings from Germany
Hi,
lets say we have a property in MXMLViaNew, like this:
public var my_var:int=10;
How do you get it from ViewTemplate.mxml ?!?
I tried many ways but didn't get one working :(