My New Love for mx.core.View

Old class (circa September 03, 2003, 2:49:24 AM… late night Nigel, hehe, or is that Cali time since I’m 3 hours ahead?), but I only now gained an appreciation for it. I was looking into a common pattern Flex uses in creating and deleting children (movieclips/components). Since a lot of the components in Flex are containers, they inherit from View up their inheritance tree, and therefore have the createChild, destroyChild methods. The createChild method is nicer (to me) than the createClassObject for a few reasons:
– shorter to type
– takes 3 parameters; the class name | the instance name | an init object, createClassObject takes 4; the 3rd being the depth

Ex, UIComponent:

createClassComponent(Label, "my_lbl", getNextHighestDepth());

vs. View:

createChild(Label, "my_lbl");

…ahh, removing un-necessarey implementation details; OOP rulez.

Additionally, View, the Flash version, already has the boundingBox_mc property defined, and already has the code to remove it in the constructor so you don’t have to repeatedly define this in your classes the extend UIComponent.

It also already sets up tabbing for children within your component by running the 2 methods I always end up repeatedly typing into my own classes:

tabChildren = true;
tabEnabled = false;

It also automatically implements a rect border; I believe this is used for borderStyles; you can see a good example of this in the Loader component, the comp used to load external content.

yourLoader.setStyle("borderStyle", "inset");

Your draw and size functions are replaced with doLayout, which you have to call super on. Additionally, for one-time layout deals, you can implement initLayout and call super on it; it’s good for stuff you’d typically put in your createChildren (have to call super in this one too), but didn’t necessarely have to do with creating children clips.

You end up with a really nice class file structure going that is more lean than the UIComponent version.

View
– constructor // good practice
– createChildren
– doLayout
+ init & initLayout optional

vs.

UIComponent
– constructor // good practice
– init (calling super)
– createChildren
– draw (for your backgroundRect mostly)
– size
+ boundingBox_mc in your properties

I typically run my getter/setters to set themselves in the initLayout, but you could do it in the createChildren if you really wanted.

…however, View appears somewhat unfinished in the Flash version (and both are missing the implementation of convertToUIObject, which converts externally loaded content via createChild to a UIObject… well, it appears that’s what it was eventually supposed to do).

Update on convertToUIObject from off-blog email:

…convertToUIObject is actually implemented in mx.core.ExternalContent. I guess it would be considered a mixin without a target. It’s a little weird.

Here’s the part of ExternalContent.as that references View:

static function classConstruct():Boolean
{
	var v = View.prototype;
	var p = ExternalContent.prototype;
	v.loadExternal = p.loadExternal;
	v.prepareToLoadMovie = p.prepareToLoadMovie;
	v.waitForUnload = p.waitForUnload;
	v.checkLoadProgress = p.checkLoadProgress;
	v.contentLoaded = p.contentLoaded;
	v.convertToUIObject = p.convertToUIObject;
	return true;
}
static var classConstructed:Boolean = classConstruct();

View loads mx.core.ExternalContent and ensures that it’s actually there (i.e. not just loaded for type checking) by including this code in the class definition:

// this never gets called, it just makes sure the external content module gets loaded
static function extension()
{
	mx.core.ExternalContent.enableExternalContent();
}

Now, that’s ok for the Flex version… but you’ll start to realize that the Flash version is missing some important children management functions. UIComponent has destroyObject, which takes care of removing the movieclip/child component, authortime or not, and deletes the variable. It’s a bit unweidly because it takes a string, I guess because they assume your gonna keep a list of skin clips like some of the components do… not me.

Case in point, destroyChildAt; its expecting a number which represents which child to remove. Do you know what child is 3? Do you know what # your submit_pb is? I don’t either, nor do I wanna manage that crap… the whole point of a helpful base class is to be… well, helpful.

Looking in the Flex version, it implements some of the necessarey methods to prevent you from having to manage this information yourself; namely:
– getChildAt(index:Number)
– getChildIndex(child:UIObject)
– destroyChild(child:UIObject)

Implementing these methods yourself is trivial, and the Flex implementations of them are not to my liking (I didn’t like the way Flex wrote the innards of those functiosn), which is a good thing since my implementations have no relations… except the end result; managing my children for me.

It has a few other useful methods too, but I don’t really need those; adding the above, including destroyAllChildren via my own, quick implementations, makes View a superior class to use for visual components that implement heavy use of Composition; a lot of sub-movieclips/components used in a wrapper class, AND with less code.

mx.core.View is not for everyone… hell, mx.controls.Label extends UIObject! I am definately digging it though for a lot of my fixed-sized forms I’m building in Flash (miss you Flex!); leaner code, and less I have worry about writing, and instead focus my time on writing application specific code.

Check out View today!

2 Replies to “My New Love for mx.core.View”

Comments are closed.