September 16, 2003
After digging into the component classes a bit (more specifically, the base classes UIObject and UIComponent), I came across something quite strange in my eyes. One of the functions of UIObject (which is essentially the base class for all components - it extends MovieClip directly) is to support events, so that if you extend UIObject, you will be able to use these "event dispatching" capabilities in your subclass.
However, after looking in the UIObject class file, I noticed that the only things that are there in relation to events is a few "empty" functions like "addEventListener", "removeEventListener", "dispatchEvent", etc. So it seems that there is actually no event implementation in the class at all!
Then, I proceeded to look in the "EventDispatcher" class file which is the base class for all event dispatching and listening (at first glance, it looks like EventDispatcher is functionally equivalent to ASBroadcaster in MX). This didn't really help me either in terms of how UIObject uses it to add/remove listeners and dispatch events.
Then, I went to the FlashCoders list because I figured some highly intelligent person would be there who would be able to give me an answer to this very fundamental question. And who steps up to the plate...? Peter Hall (flash guru extraordinaire) and Nigel Pegg (component engineer).
Anyway, to sum it up, what I learned was this...
Essentially, there are classes called "mix-ins" in the V2 component architecture. Their purpose is to add functionality to other classes without actually creating subclasses. Why not just put that functionality in the first class to begin with? Well, first off, you want base classes to be fairly generic so you don't necessarily want to clutter it with a bunch of methods that won't be used in most situations. Second, by doing this, you save file size because your base class is lighter and you only download the stuff you need in that class, as well as the other classes that are relevant to what you are doing in any given project.
Anyway, it seems that mix-ins work in the following way (I hope i'm getting this right):
1) Your mix-in class implements a set of methods/props that you want to be "mixed into" another class to extend the functionality of that class.
2) Your mix-in class generally has an "Initialize" method that is passed a reference to a class and adds the methods/props from point #1 to that class by looping through an array containing the method/prop names you want to add, and copying references(?) of those methods/props (from an instance of itself created inside the mix-in class) into the prototype property of that class. Don't know if that made sense...
3) What you end up with is a class that has a bunch of new methods/props that were added on the fly. This proves that "prototype" can actually be very useful when trying to make classes act "dynamic".
So why is this relevant in the case of UIObject? Well, I don't know if the implementation of all of this really is relevant, however, the concept is. Getting back to "event dispatching", there is actually another class called "UIObjectExtensions" (described as a static helper class by Nigel) which is used to add the event functionality to UIObject. When the "Extensions" method of UIObjectExtensions is called, it sets up event dispatching capabilities for UIObject.
So when is this Extensions method called? Well, it's actually called inside of the UIObjectExtensions class itself, so that it automatically runs once that class initializes. How is this connected to the actual UIObject library symbol? Well, if you look inside the "ComponentFLA" file library, you'll see a symbol called UIObject (which is connected to the UIObject class) and in frame 2 of that symbol, you'll see one symbol that is connected to UIObjectExtensions. So, when you drop that UIObject symbol into your custom component, everything should work like a charm.
Hope I haven't missed too much...Posted by philter at September 16, 2003 11:08 AM