Its the framework dummy!

There has been an awful lot of "noise" in recent weeks from the flash fanatics about how bad MX2004 is but as one of the those Java J2EE developers who MM maybe were trying to target with MX2004 I have to say that I really love it!!

That's not to say everything is rosy in this brave new world, but my beef with MX2004 is not so much with what they have tried to do but the way it was done......... namely the new framework!

Lets start by talking about one particular aspect of the framework that I feel represents one of its more serious flaws.

The framework fundamentally is composed of two tiers. One tier is the components tier, i.e. the visual elements that we see, like comboboxes, grids etc. The second low level tier underlies the component tier and seems to be patching broken functionality in the player or extending the player for missing basic functionality.

A good example of this is the DepthManager class.

This class extends the MovieClip's limited depth management capabilities by adding features like the ability to insert into a layer above or below a target by shuffling existing layers up or down to make space or features like reserving depths for special classes like tooltips or finding a vacant depth rather than simply the next highest.

It turns out this sort of functionality is really essential to anyone who is serious about trying to manipulate flash movies regardless of the component framework in use and it seems MM agrees as they decided this was so "core" that they made the Depth Manager implement its functionality by changing the MovieClip prototype rather than have it function as a real class object.

Ok so whats the problem here, isn't this a good thing?

Well buried inside the DepthManager is a call to a method of MovieClip called createClassObject. Didn't know that this was a MovieClip method? Well neither did I. Is it an undocumented method maybe? No, you see buried away elsewhere in a tiny corner of the framework is another class UIObjectExtensions. This class is also adding to the MovieClip prototype but it is doing it by using methods of the class UIObject, the foundation class of the whole framework, instead of using defining its own methods.

So DepthManager requires UIObjectExtensions which requires UIObject which requires...... well........
Practically the whole damn framework gets "included" one way or another and this is really symptomatic of how this whole low level tier has been implemented.

The problem with this is two fold, firstly because the implementation is so interconnected it will be almost impossible to migrate this core functionality into the player at a future date and derive any benefit from it.
Imagine for a moment that MM saw the light and realized a huge performance gain could be achieved by adding this functionality to the player in say Flash 8. Now when they release Flash 8 what are MM going to do in the framework. If they remove these functions from the framework as they are no longer needed then they will break all Flash 7 or lower apps in the same way they have just done to FlashMX or lower apps but this time they wont have the argument that it was needed to get the fundamental architecture right. Do you imagine they will be willing to do this a second time? Not likely! So they are probably going to have to leave it in there.

The second problem is that say as a developer of an independent framework of components, maybe like GhostWire, I need this same functionality and instead of creating another standard and possibly having conflicts with existing MM code I would like to make use of the DepthManager, well in doing so I will have to bring in all the code in the framework, unnecessarily burdening my app with code it doesn't use or want and eliminating many of the benefits of a streamlined lightweight framework.

So this is bad for both MM and for independent developers.

But enough of my complaints, could I have done it any better?

Well maybe, lets say if the patches and basic extensions had been packaged up in a single independent class say called "SystemExtensions" then it would allow for changes in future player versions to be handled inside this class by checking the player version at run time and adding the appropriate missing functionality. Its only executed one time so speed is not really a big issue here.

Now one obvious problem with this is how to get all the framework classes to compile if the make calls to any of these "extensions" as the compiler is unaware that MovieClip has been changed.
Well the answer is simple, MovieClip2. Create a base class MovieClip2 that extends MovieClip and simply DECLARES but not implements these extension methods and then make UIObject extend from MovieClip2 not directly from Movieclip.

Now the compiler is happy and it doesn't matter whether the functionality is implemented directly in the player or in an extension class, our application will self adapt to take account of optimizations built into future players, and it is even trivial to "backport" the extension class as newer versions of flash are released so that even those who don't upgrade can benefit from player enhancements.