Learned something this weekend about how to do multiple inheritance in Flex after going through the FileIO examples from this DevNet article. It’s something very fundamental to how Flex works, and the fact that I’ve made it this far in my Flex career without knowing it either A, clearly illustrates how powerful composition is in Flex, or B, how rarely I extend more than 1 base class.
Extending a class in Flex via MXML is easy. If you want to extend any class, you merely make it the root tag in your MXML. Below, I’m extending mx.containers.VBox:
<?xml version="1.0" encoding="utf-8"?>
<mx:VBox
xmlns:mx="http://www.macromedia.com/2003/mxml"
width="400" height="400">
<mx:Form>
<mx:FormItem label="Username:">
<mx:TextInput id="username_ti" />
</mx:FormItem>
<mx:FormItem label="Password:">
<mx:TextInput id="password_ti" />
</mx:FormItem>
</mx:Form>
</mx:VBox>
When mxmlc.exe, the command line compiler Flex uses, converts that to ActionScript, you are basically doing:
import mx.containers.VBox; class Login extends VBox { // create children code }
Both would look like this:
I’d save this as Login.mxml. However, from this point on, I’d usually use Login.mxml as a component in another component/class. I’d never want to “extend” my Login component to do something else… until recently.
Flex 1.5 uses a lot of mixins, since it’s based off of a lot of the Flash MX 2004 v2 component codebase. As such, most mixins are best used by being applied to an abstract base class, with which you later extend the abstract base class. It’s called abstract because you never actually instantiate the class itself; it’s merely there for inheritance purposes only; it was made only for being extended, not for being used.
Since ActionScript currently does not support multiple inheritance, the easiest way to fake it in ActionScript 1 and 2 is to utilize mixins; classes that utilize the Decorator pattern to add methods and properties to a class at runtime.
The downside to this is, even though you can define the properties and methods in your class so your compiler doesn’t bitch, adding event listeners for events that don’t yet exist is problematic, ecspecially if you don’t have control of the mixin. Case in point, mx.controls.listclasses.DataSelector.
This class adds basic list functionality to your class as well as support for dealing with dataproviders. The problem? The class the mixin is applied to cannot use modelChanged after the first listener. Quite frustrating, as I’ve written about before. You can use a static initializer that is run after the mixin’ to further overrwrite the modelChanged function on the class’ prototype to force it to call yours.
While that works, you’re still left with a quite unweidly class to start writing your own logic. The class itself works mind you, but if you’ve seen the DataSelector template your supposed to copy so your class will compile, it’s a LOT of stuff.
So, best to extend.
…problem was, I didn’t know how to do that in Flex, nor really know how to ask the question. So, I used the prototype hack. This was really the ONLY time I wanted to actually ever extend one of my components, and while I could of fallen back to using pure ActionScript, it’s just too much work to write all of that GUI interaction in ActionScript when MXML is faster, and easier to change without breaking my code.
So, looking through the FileIO examples, and I see they build a component, and then extend it by using the component’s name as the root tag. Well… DUH! Of course, how could I be so short-sighted? That is exactly how you extend, and have been, extending existing built in components, why would it NOT work for MY components?
Example:
<?xml version="1.0" encoding="utf-8"?>
<Login
xmlns:mx="http://www.macromedia.com/2003/mxml"
xmlns="*"
initialize="initLogin()">
<mx:Script>
<![CDATA[
private function initLogin():Void {
var so:SharedObject = SharedObject.getLocal("username");
if(so.data.username != null)
{
username_ti.text so.data.username;
}
}
]]>
</mx:Script>
</Login>
I managed to code Director for a year before learning how to return values from function calls. Apparently, one can go longer than that in Flex without knowing how to do more than 1 level of inheritance.