Toute expérience de migration Flex 4?

https://stackoverflow.com/questions/1563482

21-09-2019
|

Question

Ma pile de développement actuel est MySQL + iBatis + printemps + intégration BlazeDS printemps + 1.01 3.2 et BlazeDS Les Flex 3 avec le cadre Maté 0.8.9. Maintenant, Flash Builder 4 beta 2 est sorti. Il y a des fonctionnalités intéressantes comme données Centric développement (DCD), génération de forme etc ... Savez-vous comment l'intégration BlazeDS printemps fonctionne avec BlazeDS 4? Qu'en est-il Maté? Y at-il des problèmes avec Flex 4? Comment DCD convient avec eventmaps mate. Je sais qu'il est préférable de l'essayer moi-même, mais je veux juste vérifier si quelqu'un a déjà essayé de migrer Flex 4. Si oui, quels sont les enjeux? Avez-vous remarqué une vitesse de productivité jusqu'à? Merci.

La solution

Je ne peux pas vous dire quoi que ce soit au sujet de la migration de vos composants tiers. Je ne suis pas utiliser celles que vous avez mentionnés.

Je peux vous dire, cependant, que vous ne pourrez pas simplement charger votre projet existant vers le haut dans Flash Builder 4, changer le SDK à 4,0, et attends à recompiler. Un grand nombre de choses ont changé dans Flex 4, souvent de façon incompatible.

Voici ceux que j'ai rencontré à ce jour:

Vous avez maintenant deux bibliothèques de composants parallèles, Spark et MX. MX est l'ancien Flex 3 bibliothèque de composants, parfois appelée Halo, bien que ce soit techniquement juste le nom de la peau par défaut. Spark est la nouvelle bibliothèque de composants Flex 4, qui ne remplace que partiellement MX.

Ils font interopérer. Vous êtes autorisé à utiliser à la fois dans une seule application, et vous pouvez faire des choses comme mettre les composants Spark dans des conteneurs de mise en page MX comme ViewStack. Il y a aussi des divisions naturelles dans une application où il est possible d'avoir un côté en utilisant Spark, l'autre MX, sans vous soucier des problèmes parce qu'ils n'interopérer pas à un niveau de l'interface graphique. Les boîtes de dialogue sont comme ça, par exemple.

La raison pour laquelle ils ont fait tout cela est de soutenir ce nouveau truc de skinning vous avez entendu parler: flash Catalyst, FXG , et tout cela. Si vous utilisez le stock peau Halo, je ne vois pas que les questions de Spark vous, autre que le fait que ce soit L'avenir .

(A part: Quelle est la syntaxe Markdown pour obtenir le Magicien d'Oz boomy effet d'écho)

Joan Lafferty (Flex SDK Lead de qualité) a un article précieux, Différences entre Flex 3 et Flex 4 . À la page 4 , elle a un tableau répertoriant les composants Flex 3 MX que n'ont pas été remplacés par des composants Spark dans Flex 4. la plupart d'entre eux ont aucune apparence de leur propre, comme Accordion, de sorte que vous n'avez pas besoin de les dépecer, ou sont des choses comme les boîtes de dialogue, comme Alert. (Vous devriez lire le reste de cet article. Il couvre les choses que je fais pas, parce que je ne l'ai pas courir dans toutes les différences encore.)
En parlant de peaux, seulement deux des peaux MX de Flex 3 sont toujours pris en charge dans Flex 4. Les peaux MX plus colorés sont partis, mais il y a une nouvelle série de peaux à base de Spark-colorées qui montrer certains des choses que vous pouvez faire avec FXG et tel. Si vous avez vraiment aimé l'un des plus ils ont enlevé, vous pouvez sans doute les recréer au-dessus Spark, mais ce n'est pas disponible hors de la boîte.
Beaucoup de choses ont été renommé , et certains Spark le remplacement des composants MX ont des interfaces différentes et ont donc noms différents . Par exemple, pour passer entièrement à Spark, vous devrez changer vos VBoxes à VGroups. Il y a beaucoup de différences peu ennuyeux comme ça.
En raison de toute chose à double bibliothèque graphique, Adobe se sont retrouvés avec un tas de balises MXML comme <Script> et <Style> qui ne fait pas partie de MX, qui fonctionnent aussi bien pour Spark. Plutôt que d'avoir un ensemble de balises en double, ils ont déménagé à ceux-ci un nouvel espace de noms XML. Ceci est un problème pour ceux qui font la migration des applications basées par morceaux MX-existants, parce que cela signifie que vous utilisez encore l'alias mx pour la bibliothèque de composants MX, de sorte que ces balises qui sont communs aux deux bibliothèques doivent tous être renommés. La nouvelle valeur par défaut d'espace de noms XML pour ces balises est fx, de sorte que chaque <mx:Script> doit être renomméà <fx:Script>, et ainsi de suite. L'IDE ne le fait pas pour vous sur l'importation du projet. Vous les trouverez un par un que vous essayez d'obtenir votre projet importé à construire.

Si vous avez l'intention de passer entièrement à Spark, vous pouvez éviter une certaine douleur ici. Au lieu d'accepter l'alias d'espace de noms par défaut fx sur les étiquettes non-MX, vous pouvez le laisser continuer à utiliser mx, puisque vous ne aurez pas besoin que pour MX et Spark utilise s comme sa valeur par défaut.

Votre première tâche après l'installation de Flash Builder 4 devrait être de générer un nouveau projet afin que vous puissiez l'étudier et des choses de copier-coller comme ces déclarations d'espace de noms de lui.
Une autre retombée de l'ensemble MX vs mess Spark et espace de noms est que votre CSS pourrait avoir besoin de peaufinage. Flex a une extension non standard CSS pour ce qui ressemble à ceci:
```
@namespace mx "library://ns.adobe.com/flex/mx";
mx|Application {
    ....
```
Toutes les URL d'espace de noms ont changé à la fois entre Flex 3 et Flex 4, et dans au moins une instance nouveau changé au cours du processus bêta Flex 4.

http://www.adobe.com/2006/mxml est maintenant http://ns.adobe.com/mxml/2009 library://ns.adobe.com/flex/halo est maintenant library://ns.adobe.com/flex/mx
Le formulaire de local() pour spécifier les noms de polices incorporées par leur nom commun en CSS ne fonctionne pas plus. Vous devez utiliser le formulaire de url() et donner le chemin d'accès au fichier de police.

Un piège de se méfier d'ici est que cela signifie que si vous intégrez plusieurs variantes d'une seule police (par exemple, le poids normal et gras) votre code précédent fait référence au même nom de la police, mais votre nouveau pointera vers deux différents fichiers parce que les deux poids ne sont pas dans le même fichier .ttf ou .otf. Par exemple, ceci:
```
@font-face {
    src: local("Verdana");
    fontFamily: VerdanaEmbedded;
    fontWeight: normal;
}
@font-face {
    src: local("Verdana");
    fontFamily: VerdanaEmbedded;
    fontWeight: bold;
}
```
doit être changé à ceci:
```
@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;
}
```
Dans Flex 3, le compilateur deviné que deux fichiers de police .ttf le code ci-dessus fait référence à base de l'attribut fontWeight. Dans Flex 4, le compilateur vous fait dire explicitement.
Si vous intégrez des polices dans votre application et continuer à utiliser les contrôles MX, le texte est susceptible de disparaissent ou revenir à la police par défaut. En effet, par défaut, Flex 4 utilise un mécanisme d'incorporation de polices différentes sous le capot pour soutenir le moteur de rendu des polices améliorée dans Flash Player 10. Pour intégrer une police de la manière plus afin que les anciens contrôles MX peuvent toujours l'utiliser, vous doivent définir l'attribut CSS embedAsCFF à false.
Le mécanisme des états est tout à fait différent. Ce 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>
```
devient ceci dans Flex 4:
```
<mx:State name="alternate"/>
....
<mx:Form ...>
    <mx:TextInput id="myField" editable.alternate="false"/>
    ....
</mx:Form>
```
La nouvelle façon plus de sens pour moi, car il met tous les états de composants individuels dans la balise composant lui-même, au lieu de chemin en haut du fichier MXML dans un bloc de <mx:State> bavard, mais le portage vers le nouveau mécanisme est un peu d'une mouture. La conversion est pas automatisé par l'EDI, bien qu'il pourrait vraiment être.
Il y a quelques balises ne peuvent plus que les enfants directs de la balise <Application>. Elles se divisent en plusieurs catégories: validateurs, effets, etc. Vous devez maintenant emballer ces en une nouvelle balise <fx:Declarations>, comme suit:
```
<fx:Declarations>
    <mx:Dissolve id="myTransition" duration="100" target="{this}"/>
</fx:Declarations>
```
Il y a une nouvelle option de projet dans Flash Builder qui vous permet de continuer à utiliser le SDK Flex 3.5 seul, sans étincelle du tout, pour faciliter la migration. C'est bon pour les tests initiaux, mais à un moment donné que vous voulez aller de l'avant, à quel point vous devez composer avec tout ce qui précède.

Le nouveau compilateur ne semble pas moi tout ce que beaucoup plus rapide, soit. Je ne l'ai pas benchmarkée, juste aller sur la sensation, qui est ce qui compte vraiment pour moi, car il me fait encore sentir comme marteler ma tête sur mon bureau. :) Il est certainement pas en utilisant les 7 autres noyaux dans ma boîte de développement. Grrr.

Autres conseils

Voici quelques choses qui pourraient aider:

La version la plus récente de BlazeDS est 3.2.0.3978. Je ne l'ai pas entendu les annonces d'une nouvelle version.
Puisque vous garderez la même version de BlazeDS, le portage de votre code existant à Flex 4 ne devrait avoir aucun effet sur votre arrière (intégration Spring BlazeDS, iBATIS, MySQL, etc.).
Maté ne supporte pas encore officiellement Flex 4. J'ai eu des erreurs de compilation lorsque j'ai essayé de changer. Voici un lien vers une discussion sur les solutions de contournement Flex 4 ports .

Bonne chance!

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow