Flex 4 Namespaces and the Boy Who Cried EPIC FAIL!
A few months ago I posted about being strongly adamantly against the use of Fx Prefixes in the Flex 4 SDK. In fact I probably went a little overboard – but holy crap, kittens lives were at stake! In the end the Flex team made what I think was the right decision and began moving away from Fx Prefixes in favor of using namespaces. Yay!
However, the impact of this change recently hit Aral Balkan, a prominent Flash community member, and suddenly the controversy was reborn. In Aral’s words:
My inner engineer understands that namespaces are the most elegant long-term solution. It doesn’t help that my inner engineer is feuding loudly with my inner agile development evangelist (who is appalled at the sacrifice of short-term simplicity in favor of long-term design) and at my inner user experience designer who cannot help but look at the issue from the perspective of the end user.
I think that’s an inner struggle that a lot of developers can identify with, and on both sides you see similar extremes trying to prove themselves correct. The point of contention for me, however, is the assumption that you must choose one over the other. Do you really have to give up standards for simplicity? I know a false choice when I see one.
The truth is that complexity exists in our line of work and it’s our job to recognize it, thoughtfully consider it, and offer a solution that values simplicity. I would argue that Fx Prefixing never solved a problem, it ignored the problem all together – which is bad in any circumstance. The use of namespaces however recognizes the issue and addresses it beautifully, adding consistency throughout the framework. Here, again, we could battle semantics forever, but let’s just migrate a Flex 3 application to Flex 4 and tangibly feel Aral’s pain instead.
I’m going to be covering all of the issues involved in migrating your Flex 3 application to Flex 4 as far as I know. I’ve been using Flex 4 for months and have written applications both with Fx prefixes and without. I’ve also migrated a handful of my own Flex 3 applications to the latest Flex 4. By my definition this means getting an existing Flex 3 app to compile with the Flex 4 SDK so that I can use all of the cool new features and components. If I’m incorrect, for the love of God somebody correct me.
Setup
To begin with I created a new project using the Flex 3.1 SDK. I wanted the app to be simple enough to blog about, but I also made sure to hit any pain points involved. I decided to make an application with one custom MXML component (so that I wasn’t avoiding custom component migration issues) and some CSS (because Aral’s really off on a tirade about the CSS). After I created my custom component I realized that I had already added the first namespace to my project – before even migrating! Here’s the code so far.
SparkTest.mxml
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
xmlns:test="com.test.controls.*" layout="absolute">
<mx:Style source="//assets/css/global.css" />
<test:TestControl left="0" right="0" top="0" bottom="0" />
</mx:Application>
TestControl.mxml
<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml">
<mx:Button label="Flex 4 Rules!" right="10" bottom="10" />
</mx:Canvas>
global.css
Button {
color: red;
}
Migration
So, again, the plan is to switch the SDK to compile with Flex 4 targeting Flash 10 and see what happens – and… and my app runs. Yup, you heard it here first! FLEX 3 COMPONENTS WORK IN FLEX 4 WITHOUT MODIFICATION. In fact entire Flex 3 applications compile in Flex 4 without modification. Custom components work in Flex 4 without modification. There is no need to modify your Flex 3 code when you start to use Flex 4. I’m just not sure how else to say it – but wait! I admit there is one problem, what about that CSS warning? Ah, you caught me! There is 1 step required to get your CSS working if you used Type selectors. You must add a default namespace to the top of your CSS files.
@namespace "library://ns.adobe.com/flex/halo";
Button {
color: red;
}
I submit to you the winning entry of the 1 Step Migration Challenge.
Step 1: Add @namespace “library://ns.adobe.com/flex/halo”; to the top of your CSS files!
(do I get some kind of prize for winning?)
Conclusion
This is, in my opinion, the easiest SDK migration so far, and I think it’s unfortunate that one person’s bad experience while porting code between random Flex 4 Alpha versions could cause such mass confusion. I know that the simplicity and approachability of Flex is a huge priority to everyone (yes even the vocal minority), and it’s a great credit to the SDK team that they’re able to achieve it without sacrificing standards.
Ben Stucki
BenStucki on Twitter
Ben Stucki on XBox
Subscribe to RSS
mail@benstucki.net
Wow, that has got to be the most convoluted SDK migration I have ever seen. You mean I am actually expected to manually type in one line of code in a CSS file! I just can’t believe this wasn’t thought through more clearly, or that there wasn’t some public discussion about this decision… One line of code ?? jeez. Next thing you know I am actually going to have to do some programming to make an application.
Seriously, great write up, very eloquent.
Ben Stucki in one word : Badass
Yes Ben, very well written & explained.
Awesome write-up Ben. And as your code shows right when you start off, if you have even one simple custom component, you’re already dealing with multiple namespaces. That is covered in the most basic of Flex books (I learned via Learning Flex 3 from Oreilly Publishing) and is far from difficult.
I hope you’re right, Ben. I haven’t been using any Flex 4 stuff for my current work so I’ve not been following any of the namespace controversy until just this week. I had noticed the Fx prefixes and was a bit appalled that they had chosen that route. Glad to see they fixed it.
I hadn’t quite understood why Aral (who I’d normally consider a pretty sharp, sophisticated AS3 developer) was having such troubles. Even after countless examples I still didn’t get how namespaces weren’t demonstrably better than the Fx prefix and that the only real migration pain is in moving prefix-based code to the new namespace-based code. Which, for me, shows exactly the problems with prefixes instead of namespaces!
Thanks for posting this. Looking forward to diving into Flex 4…
I like your style, man. Great post!
Wow, Ben, it really does appear to be trivial to port a five-line app from Flex 3 to Flex 4. My app had a few extra lines, libraries, skins, etc., but I’m sure that’s an edge case as far as Flex apps go.
Now, start adding Spark components to your five-line app without further modifications and you’ll get closer to a real-world migration scenario.
I fail to see how trying to minimize the migration headache from Flex 3 to Flex 4 is a bad thing.
I haven’t got extensive hands on experience with Flex 4 yet so was wondering if I missed something when Aral blogged about this. I’m a strong supporter of namespace over prefix since its not a new concept and makes more sense looking forward.
Can I conclude that when mixing spark and halo components the only issue is that you need to set a CSS namespace when using type selectors?
States in Flex 3 and Flex 4 are obviously quite different but both should still compile? i.e. you can use a Flex 3 component with the old states syntax in a Flex 4 project?
Thanks for posting this Ben!
Sweet :D
Aral, I have no issue with minimizing migration headaches except that I think your false assumptions about migration have created the headache. Assuming that your EPIC FAIL post was your first move to namespaces and that you were migrating from a previous Flex 4 alpha version, I would say that I have significantly more experience migrating real world applications. I’ll leave the Flex 4 to Flex 4 migration expertise in your hands.
i would still rather use namespaces and yes for long term purpose… its just a language construct that i think should be made use of…
call me old fashioned but seriously? one line to declare a namespace???
i tip my hat ben…
[...] my last post I demonstrated how easy it is to migrate a Flex 3 application to Flex 4, but it seems that a few [...]
Am I the only one that thinks it’s weird/bad to be building anything remotely close to production with pre-Beta software/SDKs?
I mean “Flex 4 to Flex 4″ migration? I can’t really see building anything that requires migration in Flex 4 Alpha, short of to test and learn, in which case if it was too tricky/painful/pointless to migrate, just start over.
It’s Alpha for a reason.
My experience has been similar to Ben – loaded a Flex 3 project into Flash Builder 4. used fx:Style (was mx:Style) to load style sheet, got a few CSS error warnings which were fixed by adding the namespaces in the style sheet. From there all works fine.