Need Flex Migration Help?
- Adobe ends Flash player support in 2020
- Flex apps will no longer function
- We can help migrate your app
Okay, I haven’t blogged about anything of value in a while, yet I am still here to ask a favor. Right now Adobe has a big decision to make. They need to decide whether or not to prefix all of their classes for the Flex 4 release. Simply put, developers in Flex today are used to writing a line of code that looks like this:
The mx namespace is mapped somewhere in your MXML document to a URI. That URI indicates you mean the Flex 2 or 3 component set, affectionately called Halo. Flex 4 is going to introduce a new set of components with a different organization, but Adobe is struggling with how to allow their interoperability. Right now, the proposal is to prefix the name of each of these classes with an Fx, meaning that from now on there would be
<Button/> which means the old Halo component and
<FxButton/> which means the new Flex 4 component
Now, the idea of two separate button classes is a given, it is the only way that progress can be made developing a new flex framework while maintaining any compatibility, but it is the Fx prefix that seems problematic. What happens when we go to the next version of Flex, will it be
<NewFXButton/> or <NewerFXButton/>
Overtime, people will use fewer and fewer Flex 3 components as Flex 4 evolves, but we will forever be caught with this naming convention. The alternative, and, imo, preferable way is to continue to use namespaces as we do today.
<mx:Button/> would mean the old Halo component and
<fx:Button/> would mean the new Flex 4 component
Effectively, you are simply indicating a Button and the namespace indicates which one you would like. To me, this makes a bit more sense as we are already familiar with this concept today. If you make a custom component or a custom library, you are likely already mapping a namespace to get your specific version. If you are not intermingling the two types of components (which will eventually be possible) you could simply map the namespace differently and type <Button/> again.
While there are some CSS complications that need to be addressed in either case, the primary reason for this prefix discussion seems to be Adobe’s belief that new users won’t be able to grasp the concept of mx:Button versus fx:Button. Now there are plenty of challenges a new developer faces while learning Flex, not the least of which are likely caused by the belief by some that Flex is supposed to be trivial to learn, but in my years of training and mentoring, I have never had a pupil so confused by namespaces that a minute long explanation didn’t suffice.
I am just against making every developer from this point on always have to retype a prefix. I am against deviating from what seems like a sane plan of continuing to use namespaces as we do today, and I am generally worried that the decision is being made for the wrong reasons.
So, if you have an opinion, let someone know. Please don’t just take my opinion but read about this thread on the Adobe SDK Forum and form your own. If you feel that the Fx prefix to all components is a bad idea once you understand all the viewpoints, then consider voting for this bug on Jira, which is to eliminate the prefix (and to use namespaces as we do now).
Flex is a great product that may become a great open source product. Let’s all take that seriously and take some ownership of the issues, bugs and direction.