Any Flex 4 migration experience?

My current development stack is MySQL + iBatis + Spring + Spring BlazeDS Integration 1.01 + BlazeDS 3.2 and Flex 3 with Mate 0.8.9 framework. Now Flash Builder 4 beta 2 is out. There are cool features like Data Centric Development (DCD), form generation etc... Do you know how Spring Blazeds Integration works with BlazeDS 4? What about Mate? Is there any issues with Flex 4 ? How DCD suits with mate eventmaps. I know it is better to try it out myself but I just want to check if somebody ever tried to migrate Flex 4. If so what are the issues? Did you notice any productivity speed up? Thanks.

回答1:

I can't tell you anything about migrating your third-party components. I don't use the ones you've mentioned.

I can tell you, however, that you won't be able to simply load your existing project up into Flash Builder 4, change the SDK to 4.0, and expect it to recompile. A huge number of things have changed in Flex 4, often incompatibly.

Here are the ones I've run into so far:

You now have two parallel component libraries, Spark and MX. MX is the old Flex 3 component library, sometimes called Halo, though that's technically just the name of the default skin. Spark is the new Flex 4 component library, which only partially replaces MX.

They do interoperate. You're allowed to use both in a single app, and you can do things like put Spark components in MX layout containers like ViewStack. There are also natural divisions in an application where it's possible to have one side using Spark, the other MX, with no worry about trouble because they don't interoperate at a GUI level. Dialog boxes are like that, for instance.

The reason they did all this is to support this new skinning stuff you've been hearing about: Flash Catalyst, FXG, and all that. If you use the stock Halo skin, I don't see that Spark matters to you, other than the fact that it's The Future.

(Aside: What's the Markdown syntax to get the Wizard-of-Oz boomy echo effect?)

Joan Lafferty (Flex SDK Quality Lead) has a valuable article, Differences between Flex 3 and Flex 4. On page 4, she has a table listing the Flex 3 MX components that have not been replaced by Spark components in Flex 4. Most of these have no appearance of their own, like Accordion, so you don't need to skin them, or are things like dialog boxes, like Alert. (You should read through the rest of that article. It covers things I don't, because I haven't run into all of the differences yet.)
Speaking of skins, only two of the MX skins from Flex 3 are still supported in Flex 4. The more colorful MX skins are gone, though there is a new set of colorful Spark-based skins that show off some of the things you can do with FXG and such. If you really liked one of the ones they removed, you can doubtless recreate them atop Spark, but it's not available out of the box.
Many things have been renamed, and some Spark replacements for MX components have different interfaces and so have different names. For instance, to move entirely to Spark, you'll have to change your VBoxes to VGroups. There are lots of annoying little differences like that.
Because of the whole dual GUI library thing, Adobe found themselves with a bunch of MXML tags like <Script> and <Style> that aren't actually part of MX, which work just as well for Spark. Rather than have a duplicate set of tags, they moved these to a new XML namespace. This is a problem for those doing piecewise migration of existing MX-based apps, because it means you're still using the mx alias for the MX component library, so these tags that are common to both libraries all have to be renamed. The new XML namespace default for these tags is fx, so every <mx:Script> has to be renamed to <fx:Script>, and so on. The IDE doesn't do this for you on importing the project. You just find them one by one as you try to get your imported project to build.

If you're planning to move entirely to Spark, you can avoid some pain here. Instead of accepting the fx default namespace alias on the non-MX tags, you can let it continue to use mx, since you won't need that for MX, and Spark uses s as its default.

Your first task after installing Flash Builder 4 should be to generate a fresh new project so you can study it and copy-paste things like these namespace declarations from it.
Another fallout of the whole MX vs. Spark and namespace mess is that your CSS might need tweaking. Flex has a non-standard extension to CSS for this, which looks like this:
```
@namespace mx "library://ns.adobe.com/flex/mx";
mx|Application {
    ....
```
All of the namespace URLs have changed both between Flex 3 and Flex 4, and in at least one instance changed again during the Flex 4 beta process.

http://www.adobe.com/2006/mxml is now http://ns.adobe.com/mxml/2009 library://ns.adobe.com/flex/halo is now library://ns.adobe.com/flex/mx
The local() form for specifying embedded font names by their common name in CSS doesn't work any more. You have to use url() form and give the path to the font file.

A trap to beware of here is that this means if you're embedding multiple variants of a single font (e.g. normal and bold weights) your previous code referred to the same font name, but your new one will point to two different files because the two weights aren't in the same .ttf or .otf file. For instance, this:
```
@font-face {
    src: local("Verdana");
    fontFamily: VerdanaEmbedded;
    fontWeight: normal;
}
@font-face {
    src: local("Verdana");
    fontFamily: VerdanaEmbedded;
    fontWeight: bold;
}
```
must be changed to this:
```
@font-face {
    src: url("/Library/Fonts/Verdana.ttf");
    fontFamily: VerdanaEmbedded;
    fontWeight: normal;
}
@font-face {
    src: url("/Library/Fonts/Verdana Bold.ttf");
    fontFamily: VerdanaEmbedded;
    fontWeight: bold;
}
```
In Flex 3, the compiler guessed which two .ttf font files the above code is referring to based on the fontWeight attribute. In Flex 4, the compiler makes you tell it explicitly.
If you embed fonts in your application and continue to use MX controls, the text is likely to either disappear or revert to the default font. This is because, by default, Flex 4 uses a different font embedding mechanism under the hood to support the improved font rendering engine in Flash Player 10. To embed a font in the older way so that the old MX controls can still use it, you have to set the embedAsCFF CSS attribute to false.
The states mechanism is entirely different. This Flex 3 code:
```
<mx:State name="alternate">
    <mx:SetProperty target="{myField}" name="editable" value="false"/>
</mx:State>
....
<mx:Form ...>
    <mx:TextInput id="myField"/>
    ....
</mx:Form>
```
becomes this in Flex 4:
```
<mx:State name="alternate"/>
....
<mx:Form ...>
    <mx:TextInput id="myField" editable.alternate="false"/>
    ....
</mx:Form>
```
The new way makes more sense to me, since it puts all the individual component states in the component tag itself, instead of way up at the top of the MXML file in a verbose <mx:State> block, but porting to the new mechanism is a bit of a grind. The conversion isn't automated by the IDE, although it really could be.
There are some tags no longer allowed as direct children of the <Application> tag. These fall into several categories: validators, effects, etc. You now have to pack these up into a new <fx:Declarations> tag, like so:
```
<fx:Declarations>
    <mx:Dissolve id="myTransition" duration="100" target="{this}"/>
</fx:Declarations>
```
There's a new project option in Flash Builder that lets you continue using the Flex 3.5 SDK alone, with no Spark at all, for easier migration. That's good for initial tests, but at some point you want to move forward, at which point you have to contend with all the above.

The new compiler doesn't seem all that much faster to me, either. I haven't benchmarked it, just going on feel, which is what really matters to me, since it still makes me feel like pounding my head on my desk. :) It certainly isn't using the other 7 cores in my development box. Grrr.

回答2:

Here's a few things that might help:

The most recent version of BlazeDS is 3.2.0.3978. I haven't heard announcements of a new release.
Since you'll be keeping the same version of BlazeDS, porting your existing code to Flex 4 should have no effect on your back end (Spring BlazeDS integration, iBATIS, MySQL, etc.).
Mate doesn't yet officially support Flex 4. I had compile errors when I tried to switch. Here is a link to a discussion on workarounds, and a link to a Flex 4 port.

Good Luck!