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 what I regard as the "platform" and the other as producer of a set of components. In FMX2004 though these roles have been blured to such a degree I seriously 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 with 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 in the 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. However their 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 need not be like this even if MM needed to be able to "tag" certian clips as being "components" they could have used an Interface, they introduced these in FMX2004 and then didnt use them. They could have created an IComponent interface and then required all component to implement that interface. I could then create compatible compoents that weren't derived from the framework.
I mean why should core functionality fixes onlybe available to ther own components
The framework also make regular use of mixins to alter prototypes of intrinsice objects then calls them blindly.
Give you 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