Dear Flex community and Flex engineering team, I have a challenge for you: let's make Flex 4 migration a one-step process.
Yesterday, I documented the trouble I had in porting my Flex 3 app to Flex 4 and I blamed the move from the Fx prefix to namespaces for my woes. As some of you have pointed out, some of my woes were exacerbated because I was migrating from an earlier version of the Flex 4 Alpha SDK to the latest version. This is true. However, it is also true that Flex 3 to Flex 4 migration is not trivial and will require changes to existing code, libraries, and skins, especially concerning the introduction of namespaces in CSS.
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.
That said, if we can agree on a set of core facts regarding this change in Flex 4, maybe we can take some positive action to lessen its impact:
- The introduction of language and library namespaces in Flex 4 adds additional complexity to the framework.
- The introduction of CSS namespaces may require previous code, components, and skins to be reworked when migrating from Flex 3 to Flex 4 apps. This is an undesirable, manual, and potentially error-prone process that should, if possible, be automated.
- Developers coming from non-namespaced environments will need a gentle introduction to namespaces, especially the relationship between language and library namespaces.
Given these, I'm issuing a challenge to the Flex community and the Flex engineering team:
Flex 3 to Flex 4 migration should be an automatic, one-step process. Ideally, there Should Exist (tm) an open-source script that migrates Flex 3 projects to Flex 4. This should also be used by Flex Builder to make it trivial for developers to upgrade their Flex 3 projects to Flex 4 without manual intervention.
So, what do you guys think? Who wants to take this on?
If you guys and gals agree that migrating to Flex 4 should be this simple, we need the following:
- A volunteer to spearhead the project: the volunteer should set up a project in GitHub (SVN is so last half-hour) and be prepared to put in the hours to coordinate with the other developers, etc.
- Volunteers to work on the project
- Buy-in/participation/support from Adobe so that the solution that's built will also be part of Flex Builder
Flex 4 is going to be a revolutionary release that, for the most part, makes Flex even easier to use. I am already in love with the new states feature, I love the new Gumbonents (Gumbo components), and the new keyframe animations, just to name a few new features that I've used recently. My one worry is that a manual migration process that affects existing code, libraries, and skins will overshadow these improvements and affect the adoption and transition to Flex 4. We can fix this by making Flex 4 migration a one-step process.
So, who's in?
Thoughts? Comments? Suggestions? Leave a comment!
The The Flex 4 One-Step Migration Challenge article by Aral Balkan, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 2.0 UK: England License.
Fun idea Aral. – I’m game.
I’d like to Volunteer for the project.
What do you have in mind in terms of result tool; An AIR application which can be given the project root folder for an Fx3 project, and one fat button which says “Gumbonize” ?
I’ve taken the liberty to create an Assembla space called Fx32Fx4 with Git and tickets etc. Don’t know GitHub that well, but if any one is GH expert, I’m cool with the that.
http://www.assembla.com/spaces/Fx32Fx4
Looking forward to see the outcome of this.
Cheers
Asger
Hey Asger,
Cool :)
I’d imagine the tool being a command-line utility (perhaps written in Python?) that could then potentially be used by any GUI app, including Flex Builder. Having it as an AIR app would limit its use as a headless script.
(Wouldn’t it be cool if we had a compiler that could create standalone commandline ActionScript apps?)
This would be awesome if it could convert Flex 3 State syntax to Flex 4 State syntax as that is an area of extreme refactoring for Flex 4.
See http://blog.everythingflex.com/2009/05/12/flex-3-vs-flex-4-state-management/ for sample syntax changes
Hi Rich, I agree. I didn’t explicitly state it in the post, but maybe we should. In fact, let’s use the comments to brainstorm exactly what refactorings the script would have to do to create an initial feature list.
To start:
* Add namespaces to CSS
* Convert legacy states syntax to Flex 4 state syntax
An effort of this nature is well worth it. However, I do think it’s key that Adobe engage as well since we want to make this a solution that is *readily accessible* to every Flex developer as part of FlexBuilder – not just those of us that read these blogs and frequent the open source tooling space.
The goal and tooling that you’re proposing reminds me very much of what NeXT did back in their day when they introduced enormous change into the NeXTSTEP framework. An automated conversion tool came in the box with the new release and for the most part, it handled the migration of existing code extremely well.
It also took care to mark code it could not readily migrate, and iirc, left well-marked comments throughout with pointers to migration documentation to help the developer understand *why* it made the changes that it did.
This must absolutely be a command line driven headless toolset to be effective.
Strong suggestion: start with a well structured code refactoring engine rather than write anything from scratch. The goal here is to deliver as many useful transforms as possible in the near term.
Also worth a look is the migration tool for going from Python 2.6 to 3.0. That approach is something I’d like to see Flex 4 get.
awesome initiative by Aral.Also must say Asger is just a sweet,decent,smart and courageous guy.Love you both for the efforts. All my best wishes and I would love to share the effort any kind, if I can, with my limited knowledge in Flex compared to you guys ;)
Command line tool is the best as compared to GUI.
(Agree with Aral if there would be tools to produce standalone commandline ActionScript apps :) )
I don’t understand WHY this should be open source. ADOBE should create a button with a label “Export to Flex 4″ or so…
Hold on. Do you really think that with the public beta weeks away, and the release of Flash Builder 4 only a few months away you can come up with something that Adobe will adopt?
They currently have enough on their plate getting this revolutionary release out the door.
Sorry, but I think you’re wasting your time. Adobe is doing the smart thing from a long-term perspective, and like I said, I just don’t think your effort will adopted.
@Gabriela: It should be open source so that people using the Flex SDK can make use of it also, not just people who own Flex Builder (even though I’m sure a very high percentage of Flex developers own Flex Builder and I wouldn’t want to imagine doing Flex development without it myself).
@Greg: There’s absolutely no reason to be defeatist. I’ve seen far more ambitious projects succeed in far less time (can you say Red5?) :) Feel free to sit at the sidelines and watch and use the tool once it’s created. Regardless of whether Adobe adopts it, it will be a WIN for Flex developers and for the platform to make migration to Flex 4 (and the *layering* of Flex 4 functionality into existing Flex 3 application) easier.
Nothing worth doing is ever a waste of effort. :)
Aral, is there any major change in AS? I’m a little tired to learn a new (yet powerful) language every year…
Great initiative. Would like to see this get shape. I think this should be on the minds of the Flex team. It would be better if someone from Adobe also gets involved to guide the project and ensure that it is going in the right direction.
The whole “namespace vs. no namespace” debate is a tricky one. If you’re making and using any custom components in Flex, you’re already using custom namespaces to import MXML components. How would this be new?
Aral,
This is the best response to the persnickety commentary (mine being one of them) you received for your last post. Bravo.
This is why I love this blog. Keep up the good work!
Gabriela, to answer your question: There are no changes to ActionScript. it is the same AS3 we all know and love (or love to hate).
The Flex Framework has changed. So if you intend to use the framework then you have some homework to get up to speed with Spark. If you build apps solely in AS3 then you have nothing to worry about.
[...] to make Flex 3 to Flex 4 migration as easy as possible. As such, please read my follow-up post, The Flex 4 One-Step Migration Challenge and let’s try and make a list of the Flex 4 migration challenges for Flex 3 apps and try to address [...]
So you’ll spend time creating a logo for this post but no time showing real examples proving your complaints?
I echo Ryan’s comment (and did so in the other thread and elsewhere). Where’s a concrete *example* of a migration pain? Please tell me you’ve actually done some migration work and encountered the pain, and that all of this hoo-haa isn’t based on simply your *expectation* of pain…
Read Ben’s latest retort here: http://blog.benstucki.net/?p=56. I’ve commented there.
thank yoı plp
Really needed? I dont know.
Covenient? Yesss!
What is the current status of this initiative. It sounds like something that would be very useful.
Adobe is screwing us by not making Flex 3 to Flash Builder 4 import seamless and automatic. It’s that simple. How can they change all the packages and namespaces and not provide a migration utility. It pisses me off no end.
I have a query, I import Flex 3 project into Flex 4 aka Flash BUilder 4 Beta 2, now my query is which componenet set flash will use, default Halo which I used in Flex 3 or Spark Components even without chanding the namespace. Namespcace is same: xmlns:mx=”http://www.adobe.com/2006/mxml”
pls help