Flex Component Development

If any of you regularly extend Flex 2 components then you have undoubtedly been knocked off course at some point by the need to extend or access a method or variable in the Flex framework that is declared private. Figuring out that one private variable stands between you and completion is a great way to ruin your day.

In many cases, this isn't a huge issue. There are a few ways to routinely handle it.

1. You might be able to just duplicate the variable/chunk of code required in your subclass
2. If the reference you need is actually a display object child, you can probably get your own reference to it by using getChildAt() or getChildByName(), the former being a better bet

However, there are times where these solutions are just not feasible. I had an issue overriding a behavior of FormItem once that would have required us to duplicate code and variables all the way up the inheritance stack to UIComponent. In the end, the duplication solution required almost 1800 additional lines of code... all of which were extremely fun to hand-check when the Flex 2 to 2.01 updater changed some of the lines in the base classes.

At Max '06 I complained about this to anyone that would listen. Unfortunately for each of them, I was able to grab Ely Greenfield and Sho Kuwamoto for a while. They both reiterated the same basic concept, 'we need to make some things private instead of protected as we can not support the infinite number of things developers may want to extend in their components going forward'.

This isn't a bad argument. If I extend a method and a new release of Flex arrives with that method renamed or requiring different parameters, I would be frustrated. My only counter here is that I would be a lot less frustrated with a few method changes than I will be reworking thousands upon thousands of lines of copied code.

All of that said, there is another choice to resolve this issue that, theoretically, has all of the negatives of the existing issues, but, in practice is a lot easier to maintain for a small project. I would recommend against using this strategy in all but the direst positions. I would certainly strongly recommend against using this if you are creating any type of component for redistribution to the masses.

Disclaimers aside, let's talk about the flex linker.

For quite a while I had wanted to simply recompile the Flex framework and deploy my own swc. I would simply change the variables I needed from private to protected; however, this is made impossible by missing content in the rpc classes. I had a few hundred crazy ideas and even wrote a small piece of C code that would rip through the binary making the changes I needed... but then... Kyle Quevillon (who should not be blamed for this) of Adobe Support reminded me of a little piece of information that I had forgotten.

If you attempt to link in two classes with the same package and name, the newest one wins. This provided two divergent paths of damage that one could use as an approach.

First, for example, if I needed to extend FormItem, I could simply copy all of the FormItem code, modify the properties I needed to ensure they were protected as opposed to private and link in my version of FormItem when building my project. I could then extend this FormItem class to make MyFormItem.

Critics will note at this point that if I was going to copy all of this code, I could just make my own class, which extends from the same parent as FormItem and does much less damage. This is true... but then my new class is no longer a FormItem... I loose the 'IS A' factor, which means that polymorphic checks such as if (myVar is FormItem) would no longer yield true.

With the exception of a really weird circumstance, I probably wouldn't follow the strategy above either, especially when I can cause much more damage by taking this concept further.

Following the logic above, one could substitute a new version of UIComponent for the one provided by Adobe. Any code, including classes that are included in the Flex framework, would then use this new version of UIComponent as opposed to the original. So, if my new version of UIComponent perhaps contained a protected method that arbitrarily set the background color to blue, then Container, Form, FormItem, DataGrid, etc. would all have this method as well. Fortunately, I don't want to set the background color to blue, but....

I could also (theoretically) add a set of methods something like *cough*:

While this won't solve every problem, it would allow me to get or set a reference to a pesky private variable in my super class by saying super.getPrivateVar( 'varThatSouldHaveBeenProtected' )

Now, this is bad. It is wholly incompatible and you couldn't distribute a component like this as another developer may have the same horrible idea and provide a version of UIComponent without your methods... but, in a limited use within the code of a small team, it might save a few lines of code.

In fact, in 14 large components it would save us almost 26,000 lines of duplicated code that would have to be maintained across future upgrades and releases. Ultimately, I am not advocating this, I am just saying that the framework has perhaps chosen order at the expense of innovation, and, for better or worse, I tend to try to find solutions around such order.

Code samples enclosed, ML