任何Flex 4移植经验？ [英] Any Flex 4 migration experience?

问题描述

我当前的开发堆栈是MySQL + iBatis + Spring + Spring BlazeDS Integration 1.01 + BlazeDS 3.2和Flex 3与Mate 0.8.9框架。现在Flash Builder 4 beta 2已经不在了。有像数据中心开发（DCD），表单生成等酷功能...你知道如何与BlazeDS 4的Spring Blazeds集成？那么Mate呢？ Flex 4有什么问题吗？ DCD如何适合伴侣事件地图。我知道最好自己尝试一下，但我只想检查一下是否有人试图迁移Flex 4.如果是这样，问题是什么？你有没有注意到生产力的提高？谢谢。

解决方案

我无法告诉您有关迁移第三方组件的任何信息。我不会使用你提到的那些。

然而，我可以告诉你，你将无法简单地将现有的项目加载到Flash中Builder 4，将SDK更改为4.0，并期望它重新编译。在Flex 4中，很多事情都发生了变化，通常是不相容的。

以下是我到目前为止所遇到的情况：

• 现在有两个并行组件库Spark和MX。 MX是旧的Flex 3组件库，有时称为Halo，虽然这在技术上只是默认皮肤的名称。 Spark是新的Flex 4组件库，仅部分取代了MX。
  
  

  他们做互操作。您可以在一个应用程序中同时使用这两个应用程序，并且可以像放置 ViewStack 一样在MX布局容器中放置Spark组件。在一个应用程序中也有自然的区别，在这个应用程序中，可能有一方使用Spark，另一个使用另一个MX，不必担心麻烦，因为它们不能在GUI级别进行互操作。例如，对话框就是这样的。

  
  
  

  他们这样做的原因是为了支持你已经听到的新皮肤的东西： Flash Catalyst ，，以及所有这些。如果你使用Halo皮肤，除了它是 这个事实以外，我没有看到Spark对你很重要。
  
  

  （另外：什么是Markdown语法来得到Ozz向导的回声效果？）
  
  

  Joan Lafferty（Flex SDK质量负责人）有一篇有价值的文章， Flex 3与Flex之间的区别4 。在 page 4 上，她列出了Flex 3 MX组件列表还没有被Flex 4中的Spark组件所取代。其中大部分都没有自己的外观，比如 Accordion ，所以你不需要去皮他们，或者是东西像对话框一样，如 Alert 。 （你应该仔细阅读那篇文章的其余部分，它涵盖了我没有的东西，因为我还没有碰到所有的区别。）

说到皮肤，Flex 3中只有两个MX皮肤仍然支持Flex 4。尽管有一套新的炫彩的基于Spark的皮肤展示了一些你可以使用的皮肤与FXG等做。如果你真的喜欢其中一个被删除的，你可以无疑地在Spark上重新创建它们，但它不是开箱即用的。


• 已重命名，并且MX组件的一些Spark替换项具有不同的界面，因此也有不同的名称。例如，要完全移动到Spark，必须将 VBox es更改为 VGroup s。有很多令人讨厌的小差别。

由于整个双重GUI库的事情，Adobe发现自己有一堆MXML标签，如< Script> 和< Style> ，这实际上并不是MX的一部分。他们没有一套重复的标签，而是将这些标签移到一个新的XML名称空间中。对于那些对现有基于MX的应用程序进行分段迁移的人来说，这是一个问题，因为这意味着您仍然在为MX组件库使用 mx 别名，所以这些标签这两个库的共同点都必须重新命名。这些标签的默认新XML命名空间是 fx ，所以每个< mx：Script> 必须重命名为< fx：Script> 等等。 IDE不会为您导入项目。如果你打算完全移动到Spark，你可以避免在这里的一些痛苦，你可以一个接一个地找到他们，因为你试图让你导入的项目建设。
。不接受非MX标签上的 fx 默认命名空间别名，您可以继续使用 mx ，因为你不需要MX，而Spark使用 s 作为默认值。




安装Flash Builder 4应该是生成一个全新的项目，这样你就可以研究它，并复制粘贴这些命名空间声明的东西。


• 整个MX与Spark和命名空间的混乱是你的CSS可能需要调整。 Flex对CSS有一个非标准扩展，如下所示：
  
  

    @namespace mxlibrary：// ns .adobe.com /柔性/ MX; 
   mx | 
   ... 
   Flex 4和Flex 4之间的命名空间URL已经发生了变化，并且在Flex 4 beta过程中，至少有一个实例又被改变了。
   
   
   
    http://www.adobe.com/2006/mxml 现在 http://ns.adobe.com/mxml/2009  
    library：//ns.adobe.com/flex/halo 现在是 library：//ns.adobe。 com / flex / mx  
   




• local（）嵌入的字体名称在CSS中的通用名称不再适用。您必须使用 url（）表格并指定字体文件的路径。

  
  
  

  需要注意的陷阱这意味着如果你嵌入一个单一字体的多个变体（例如正常和粗体重），你以前的代码引用相同的字体名称，但是你的新代码将指向两个不同的文件，因为两个权重不是在相同的.ttf或.otf文件中。例如：
  
  

    @ font-face {
   src：local（Verdana）; 
   fontFamily：VerdanaEmbedded; 
   fontWeight：正常; 
  } 
   @ font-face {
   src：local（Verdana）; 
   fontFamily：VerdanaEmbedded; 
   fontWeight：bold; 
   
   $ / code $ / pre 
   $ b $ p必须改为：
   
   
    @ font-face {
   src：url（/ Library / Fonts / Verdana.ttf）; 
   fontFamily：VerdanaEmbedded; 
   fontWeight：正常; 
  } 
   @ font-face {
   src：url（/ Library / Fonts / Verdana Bold.ttf）; 
   fontFamily：VerdanaEmbedded; 
   fontWeight：bold; 
   
   
   
   
   
   $ b在Flex 3中，编译器猜测上面的代码是哪两个.ttf字体文件指的是基于 fontWeight 属性。在Flex 4中，编译器使你明确地告诉它。

如果您在应用程序中嵌入字体并继续使用MX控件，则文本可能消失或恢复为默认字体。这是因为，默认情况下，Flex 4在引擎盖下使用了不同的字体嵌入机制来支持Flash Player 10中改进的字体呈现引擎。要以旧的方式嵌入字体，以便旧的MX控件仍然可以使用它，必须设置 embedAsCFF CSS属性为 false 。





 < mx：State name =alternate> 
 < / mx：State> 
 ... 
< mx：Form ...> 
< mx：TextInput id =myField/> 
 ... 
< / mx：表格> 
  

成为Flex 4中的一员：



 < mx：State name =alternate/> 
 ... 
< mx：Form ...> 
  ... 
< / mx：表格> 
  

新方法对我更有意义，因为它将所有单个组件状态放在组件标记中本身，而不是在详细的< mx：State> 块中的MXML文件的顶部，但移植到新的机制是有点磨。这个转换并不是由IDE自动完成的，尽管实际上可能是这样的。 c>< Application> 标签。这些分为几类：验证器，效果器等等。现在你必须把它们打包成一个新的< fx：Declarations> 标签，如下所示：

 < fx：声明> 
< mx：Dissolve id =myTransitionduration =100target ={this}/> 
< / fx：声明> 
  




• Flash Builder中有一个新的项目选项，可让您继续单独使用Flex 3.5 SDK ，根本没有火花，更容易迁移。这对初步测试是有好处的，但是在某些时候，你想要前进，在这一点上，你必须与上述所有方面进行抗衡。

新编译器对我来说似乎并不那么快。我没有把它做基准，只是觉得，这对我来说真的很重要，因为它仍然让我感觉像在我的桌子上敲着脑袋。 :)它肯定不是在我的开发盒中使用其他7个核心。 Grrr。

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.

解决方案

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.

这篇关于任何Flex 4移植经验？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！