Friday, January 28, 2005

Why the framework must change and why it probably wont

No not another rant against AS2 components, anyway seeing as we produce a competing set of components ourselves a rant from me wouldn't be that credible, but instead I hope here is some reasonable arguments for why the framework really needs to be overhauled.

Many have ranted about the "bloat" of MM's AS2 components and the evils of mixins, sure I have even done that myself, but here is why really these complaints miss the point. If that was all that was wrong then we and others would have jumped in with new framework components that were lighter and mixin free but you dont see them, you dont see many components that extend the framework either. Instead what you see is people completely doing away with the framework. Why?

Now a lot of these replacement components tout being lighweight alternatives to the framework but as saw someone comment ona maillist recently its not hard to produce lighweight components, the real question is not are they lighter but what features did they leave out. Complain as you might about the MM set but they are full featured and they do contain all the extra features that a components need to be used in regular applications, forms, events, tab/focus control, and data binding. Practically all the other components I have seen tend to leave out some functionality or other in order to make them lighweight. I dont believe that this is the correct approach and I think it makes claims about being lighweight alternatives somewhat dubious.

To be honest as a component developer I dont think I should have to provide these core functionalities I think they should be part of the basic enviroment.
I would drop our own implementations in a heartbeat if MM provided a way for me to use there FocusManager or DepthManager but here lies the heart of the problem.

You see I believe MM wear two hats when it comes to Flash one as developer of the FLash VM and core classes and the other as producer of a set of components. InFMX2004 though these roles have been blured indeed I believe the architecture is so poorly thought our that these roles are now so inextriciably interlinked that I doubt it can be fixed. The framework is a mix of patches and extensions to the core VM and base classes and classses for component development but the two are interlinked in such a way that you cant have one without the other.

Two examples to show the point.
MM realise that Focus Management is broken inthe player but instead of fixing the player they wrote the fixes in actionscript, I dont believe that was a good idea but none the less that isn't really critical by itslef. However there fix makes use of UIObject, the core of the component framework, and whats more actually in its code to build a tab list it checks to see whether a control is a UIElement or not.

So you cant use the FocusManger with your own components unless you are happy to have the whole framework dragged in and you also need to be subclass of UIObject in order to take full advantege.

You either have the framework or you dont have the VM fix simple as that.

It shouldnt be like this even if MM needed to be bale to "tag" certian clips as being "components" they could have used an Interfae, they introudced hese in FMX2004 and then didnt use them. They could have created a IComponent interface and then required all compoent to implement that interface so I could create compatible compoents that werent derived from the framework.
I mean why should core functionality fixes onlybe availe to ther own components

The framework also make regular use of mixins to alter prototypes of intrinsice objects then calls them blindly.

Giv eyou an example of how bad this can be.

I had a class bound to a clip it made no use of the framework and just extended from my own base class. I was puzzled as to why when I dropped an MM TextInput control onto it the TextInput control "lost" its styling. I tracked this down to UIObject making a call to _parent.getStyle and in my class I had a private method getStyle. This is very bad MM component made no attempt to check whether it was calling another UIObject its just assumed that since it had "fixed" all movieclips prottyppes it was safe to do it. Thats bad architecture not only did it screw up their component it screwed up mine as well. In our own components we dont later prototypes and we have a "parent" property that we set to the next object in hierarchy above us thatis part of our base class so we only make calls to our owns components.

These things need to be changed separate core VM fixes form the component framework, use Interface as tags not insisiting on deriving from a class.

Make this an open platform and people willbe able to extend and improve it and in so doing it will increas the interest and use instead of currently where there is practically only a choice of either using MMCompoents or not using flash.

No comments:

Post a Comment