Je ne peux rien vous dire sur la migration de vos composants tiers. Je n'utilise pas ceux que vous avez mentionnés.
Je peux vous dire, cependant, que vous ne pourrez pas simplement charger votre projet existant dans Flash Builder 4, modifier le SDK à 4.0 et attendre qu'il soit recompilé. Un grand nombre de choses ont changé dans Flex 4, souvent incompatibles.
Vous avez maintenant deux bibliothèques de composants parallèles, Spark et MX. MX est l'ancienne bibliothèque de composants Flex 3, parfois appelée Halo, bien que techniquement c'est juste le nom de l'habillage par défaut. Spark est la nouvelle bibliothèque de composants Flex 4, qui ne remplace que partiellement MX.
Ils interopèrent. Vous êtes autorisé à utiliser les deux dans une seule application, et vous pouvez faire des choses comme mettre des composants Spark dans des conteneurs de disposition MX comme ViewStack. Il existe également des divisions naturelles dans une application où il est possible d'avoir un côté utilisant Spark, l'autre MX, sans se soucier des problèmes car ils n'interopèrent pas au 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 supporter ce nouveau skinning dont vous avez entendu parler: Flash Catalyst, FXG, et tout ça. Si vous utilisez le skin Halo en stock, je ne vois pas que Spark compte pour vous, à part le fait que c'est The Future.
(A part: Quelle est la syntaxe Markdown pour obtenir le Magicien d'Oz caverneux effet d'écho?)
Joan Lafferty (Flex SDK Lead de qualité) a un article précieux, Differences between Flex 3 and Flex 4. Sur page 4, elle a un tableau listant les composants Flex 3 MX qui n'ont pas été remplacés par des composants Spark dans Flex 4. La plupart d'entre eux n'ont pas leur propre apparence, comme Accordion, donc vous n'avez pas besoin de les habiller, ou des choses comme des boîtes de dialogue, comme Alert. (Vous devriez lire le reste de cet article qui couvre les choses que je ne connais pas, car je n'ai pas encore rencontré toutes les différences.)
En parlant de peaux, seulement deux des peaux MX de Flex 3 sont toujours pris en charge dans Flex 4. Les skins MX les plus colorés ont disparu, bien qu'il existe un nouvel ensemble d'enveloppes Spark colorées qui montrent certaines des choses que vous pouvez faire avec FXG et autres. Si vous avez vraiment aimé l'un de ceux qu'ils ont enlevés, vous pouvez sans aucun doute les recréer au sommet de Spark, mais ce n'est pas disponible hors de la boîte.
Beaucoup de choses ont été renamed, et certains remplacements Spark pour les composants MX ont des interfaces différentes et ont donc different names. Par exemple, pour passer entièrement à Spark, vous devrez changer votre VBox en VGroup s. Il y a beaucoup de petites différences ennuyantes 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 sont pas en fait une partie de MX, qui fonctionne aussi bien pour Spark. Plutôt que d'avoir un ensemble de balises en double, ils les ont déplacés vers un nouvel espace de noms XML. C'est un problème pour ceux qui effectuent une migration par morceaux d'applications MX existantes, car cela signifie que vous utilisez toujours l'alias mx pour la bibliothèque de composants MX, donc ces balises communes aux deux bibliothèques doivent toutes être renommées. Le nouvel espace de noms XML par défaut pour ces balises est fx. Par conséquent, chaque <mx:Script> doit être renommé <fx:Script>, et ainsi de suite. L'EDI ne le fait pas pour vous lors de l'importation du projet. Vous les trouvez un par un alors que vous essayez de construire votre projet importé.
Si vous envisagez de passer entièrement à Spark, vous pouvez éviter la douleur ici. Au lieu d'accepter l'alias d'espace de noms par défaut fx sur les balises non-MX, vous pouvez le laisser continuer à utiliser mx, puisque vous n'en aurez pas besoin pour MX, et que Spark utilise s comme 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 copier-coller des choses comme ces déclarations d'espace de noms. Une autre retombée de l'ensemble MX contre Spark et le désordre de l'espace de noms est que votre CSS pourrait avoir besoin de peaufiner. 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 un cas changé à nouveau pendant le 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 local() pour spécifier les noms de polices incorporées par leur nom commun en CSS ne fonctionne plus non. Vous devez utiliser le formulaire url() et indiquer le chemin d'accès au fichier de police.
Un piège à se méfier d'ici est que cela signifie que si vous incorporez plusieurs variantes d'une seule police (par exemple, poids normal et gras), votre code précédent fait référence au même nom de police, mais votre nouveau différents fichiers car 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 devina 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 le dit explicitement. Si vous incorporez des polices dans votre application et continuez à utiliser les contrôles MX, le texte risque de disparaître ou de revenir à la police par défaut. En effet, par défaut, Flex 4 utilise un mécanisme d'incorporation de police différent sous le capot pour prendre en charge le moteur de rendu des polices amélioré dans Flash Player 10. Pour incorporer une police de manière plus ancienne, les anciens contrôles MX peuvent toujours l'utiliser. devez définir l'attribut CSS embedAsCFF sur false.
Le mécanisme des états est entièrement 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 en haut du fichier MXML dans un bloc verbeux <mx:State>, mais le portage vers le nouveau mécanisme est un peu un grind. La conversion n'est pas automatisée par l'IDE, bien qu'elle puisse l'être.
Certaines balises ne sont plus autorisées en tant qu'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 ceci:
<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 la Flex 3.5 SDK seul, sans Spark du tout, pour faciliter la migration. C'est bon pour les tests initiaux, mais à un moment donné, vous voulez aller de l'avant, à quel point vous devez faire face à tout ce qui précède.
Le nouveau compilateur ne me semble pas beaucoup plus rapide. Je ne l'ai pas référencé, je vais juste sentir, ce qui compte vraiment pour moi, car ça me donne toujours envie de marteler ma tête sur mon bureau. :) Il n'utilise certainement pas les 7 autres cœurs dans ma boîte de développement. Grrr.
Est-ce que l'étincelle vaut tous ces problèmes? – Amarghosh
J'ai modifié ce qui précède pour ajouter plus de détails et répondre mieux à la question "pourquoi étinceler". Fondamentalement, il s'agit de dépecer. Plus de modifications sur le chemin, que je creuse à travers les diffs pour mon application ... –
L'un des meilleurs ripostes j'ai lu sur Flex. Merci – Thalaivar