Flex has been open source for a while now, so you might wonder why there doesn’t seem to be more external, community-driven extensions to the library. It seems that the only source contributors are Adobe employees. I’ll pass on the theories on why Adobe might want to keep it this way. The purpose of this post is to look at why from a strictly technical point of view it’s really discouraging to try to extend the library. I’ve tried, and these are the problems I’ve run into.
-
Flex classes are huge. Adobe seems to have taken the « everything but the kitchen sink » approach to designing Flex, so you end up with huge blobs of code with tuff and features and whatnots that have nothing to do with the class’s purpose. So obviously a big class is harder to read and extend.
-
mx_internal. Everywhere you look in Flex classes you find variables that are part of the namespace mx_internal. Since this isn’t documented, it’s anybody’s guess why the more traditional private, internal, protected and public declarations aren’t enough. The thing is you actually can use mx_internal objects, you just have to know how to. So what it the intention? Don’t use mx_internal in your derived classes unless you’re really hardcore? I’m baffled, so if anyone has an explanation please leave it in the comments.
-
Using private instead of protected. Sometimes you need access to a variable from your subclass and it’s been declared private. This happens quite often. So you end up copying the class into your workspace to modify it instead of extending it as you should.
-
This isn’t so common as mx_internal, but still annoys. Instead of using a class reference, Flex sometimes uses a path reference to a file. « include “../core/Version.as”; ». Looks crappy, right? Yeah, it is. Suppose you’ve copied the class locally, as mentioned above. The path reference won’t work, and you need to jump through even more hoops to get the job done.
That wraps it up for now. To get a good exapmple of everything I mentioned, take a look at the mx.effects.effectClasses.MoveInstance class. It does a good job, but is long, unreadable and unextendable. Don’t get me wrong, I still like Flex otherwise I wouldn’t work with it and post about it, but sometimes it gets me down.
by Anselm Bradford
03 Apr 2009 at 19:49
Yeah, overriding the Flex classes is painful
Pingback
by Rounding Up April Fool’s Week
06 Apr 2009 at 17:01
[…] While some may wonder why Adobe Flex has next to no community-inputs coming in despite being open source, Ariel tells us why he thinks extending Flex sucks. […]
by Tink
09 Apr 2009 at 04:51
mx_internal denotes that Adobe may not support backwards compatibility with those methods.
i.e. if you override public or protected methods, you can rest assured that framework updates won’t break your code.
If you extend Adobes classes includes shouldn’t affect you. If you copying their code in custom classes you can omit things like.
include “../core/Version.as”;
These ActionScript files (they are not classes) enable you to isolate and re-use code, and cutdown on the code in the class. For instance you can isolated all the border styles out into one file, and then just include that in any component that you have built to support those styles.
Basically an include is the same as doing a Script tag and setting its source property to an ActionScript file.
by admin
09 Apr 2009 at 09:07
Hi Tink,
thanks for the explanation! I’ll try to keep my hands off mx_internal then
As for includes, I can see your point, but it’s pretty bad for code portability, I find. Wrapping your code in a class and finding it a space in your codebase is probably worth your trouble in the long run.
Ariel
by bitpusher
25 Jan 2010 at 00:34
Hey Ariel,
Couldn’t agree more.
Just spent a week trying to create custom list and rendrer from ListBase an ItemRenderer.
It seems Adobe never imagined that a list could be horizontal.
I give up.
by admin
29 Jan 2010 at 10:26
Hi Bitpusher,
you can’t do what you want, but lo and behold, the horizontal list:
http://livedocs.adobe.com/flex/3/langref/mx/controls/HorizontalList.html
You can’t extend, but sometimes they do the work for you
bye
Ariel
by Garegin B
03 Apr 2012 at 07:36
First of note that Flex/AS is a Object oriented language, and requires yet another thinking approach than JS requires. As I see JS will be comparable with Flex/AS something like 10 years ago (HTML 8:) ).
What about lists, they have very effective implementations in Spark, 100% tune-able and so on. Life goes on, nothing is being immediately.