Avec adobe flex en fin de vie, je me demandais quelles procédures avez-vous suivies ou pouvez-vous penser ou pour migrer vers la dernière interface utilisateur (HTML5, AngularJS)?
Tous les liens indiquent les avantages et les inconvénients de le faire. Cependant, j'ai du mal à comprendre les étapes requises lors de la migration de la technologie de l'interface utilisateur.
6 Réponses :
La migration d'un projet Flex vers HTML / Javascript est une grande entreprise. Premièrement, si votre base d'utilisateurs est d'accord avec une application de bureau (plutôt que d'exécuter votre application dans le navigateur), vous pouvez ignorer la migration et utiliser Adobe AIR pour empaqueter l'application.
Si l'application doit s'exécuter dans un navigateur, vous devez la traduire dans un cadre moderne tel que Angular, React ou Vue. J'ai étudié ces cadres en détail et j'ai conclu que Angular / Typescript était le plus proche de Flex et le meilleur choix pour mon projet de migration, mais une partie de ce choix est la préférence personnelle. Mon expérience est:
C'est malheureusement une grande courbe d'apprentissage. Dans un premier temps, apprenez / écrivez un petit projet dans Angular ou Vue. Les deux ont TypeScript natif et il est proche de AS3. À partir de là, vous comprendrez mieux comment élaborer une stratégie de migration.
Hey ! Je me suis donc demandé comment allez-vous remplacer BlazeDS de votre projet flex lors de la mise à niveau? êtes-vous une suggestion d'appels AJAX (ou équivalent pour différents framework?)
Mon projet Flex utilisait des appels HTTP standard, donc je pouvais migrer sans changer les choses côté serveur. Si vous utilisez BlazeDS, alors oui, il doit être réécrit car il n'y a pas de remplacement à ma connaissance.
Pourquoi la traduction de code mxml est une partie difficile? Puisque les fichiers mxml sont d'abord convertis en .as, puis en swf, je me demandais si je pouvais conserver le fichier .as qui est créé lorsque mxml est compilé (ce qui est possible en passant la ligne de commande arguemnt dans le compilateur) et les convertir en dactylographié en utilisant les convertisseurs disponibles ... qu'en pensez-vous?
Regardez un .as traduit de .mxml. Il aura des appels à la VM Flash et au framework Flex qui n'ont pas d'équivalent en Javascript. Comme mentionné dans une autre réponse, Apache Royale vise à réaliser cette traduction, utilisez donc Royale si vous souhaitez emprunter cette voie.
Une autre option pour vous pourrait être Apache Royale . Il s'agit de l'évolution de Flex Framework, qui permet la transpilation du code AS3 en Javascript / HTML5. Bien qu'il ne soit pas parfait, il s'agit d'un moyen simple de migrer les anciens projets pour les maintenir en cours d'exécution.
Pour l'instant, vous n'aurez qu'à changer votre interface utilisateur des anciennes balises Flex aux nouvelles, bien que les gens essaient de faire émuler les anciens composants Spark dans le nouveau système.
En gros, vous êtes un
Si vous préférez toujours utiliser un nouveau framework js, j'ai trouvé que le plus simple pour moi à adapter était VUE.js
Je pense que Flex est mort il y a quelques années, j'ai peur. J'étais développeur flex à l'époque. Je dois dire que la transition pour moi de Flex / Actionscript à React a été difficile. J'ai trouvé que la similitude entre le langage de balisage (par exemple, MXML ou JSX (React)) et le langage de codage (Actionscript ou Javascript (React)) a un peu aidé. Si vous avez une bonne maîtrise de Javascript, cela vous aidera, si vous n'apprenez pas les bases. Utiliser React ou un autre framework signifie également utiliser les outils, un bundler (généralement webpack), vous aurez également besoin d'une connaissance pratique de Babel. J'irais pour React parce que je suis partial et c'est très très populaire. Faites-moi savoir si vous souhaitez lier des liens que j'ai trouvés utiles. Enfin, je dirais, évitez simplement Flex -> outils JS, aspirez-le, souriez et apprenez ce qui mange le Web ....
Nous avons fait quelques-unes de ces migrations maintenant et la réponse simple est "ça dépend". Vous devez répondre à certaines questions:
Est-il possible pour les utilisateurs finaux d'installer votre application localement, plutôt que d'y accéder via un navigateur Web? (Implique peu ou pas d'interaction entre votre application Flex et sa page HTML / JS contenant ..). La réponse est oui, alors la migration devient beaucoup plus simple car vous pouvez soit utiliser AIR (pour une autre réponse), soit utiliser une solution packagée pour contenir et déployer votre application telle quelle (pratiquement aucun travail pour vous, mais c'est une solution commerciale donc coûte de l'argent ..)
Êtes-vous satisfait de conserver le code source en MXML / AS3, ou préférez-vous déplacer tout cela dans un autre langage (TypeScript ou JavaScript)? Si vous souhaitez conserver le code en MXML / AS3 - et en réutiliser la majeure partie - alors Apache Royale est le choix car il dispose du transpilateur pour transformer MXML / AS3 en JavaScript. Si vous ne souhaitez pas utiliser MXML / AS3, vous devez choisir un nouveau framework TS / JS.
Avez-vous beaucoup d'appels aux API Flash, ou simplement aux API Flex? Apache Royale prend en charge de nombreuses fonctionnalités équivalentes à celles de Flash (événements, utils, etc.), mais il se concentre principalement sur les API Flex. Il y a même des efforts pour essayer d'obtenir un mappage proche de 1: 1 entre les composants Flex et les nouveaux composants Royale afin que l'effort de portage soit encore moindre. Mais les API Flash devront souvent être converties manuellement (par exemple, nous avons créé un certain nombre d'implémentations dans Royale pour les classes flash.media. *).
Plus j'utilise Royale, plus je l'apprécie. Il y a un peu de courbe d'apprentissage pour commencer, mais lorsque vous vous rendez compte que n'importe quel composant JavaScript est également accessible à partir de cela, cela devient assez puissant. Il est préférable de fournir des wrappers pour ce genre de choses (de la même manière que vous pouvez obtenir des définitions TypeScript pour eux), car vous bénéficiez alors des avantages de la vérification de type, etc. de la chaîne d'outils.
Je suis en train de migrer une application Web d'entreprise massive de Flash / Flex vers Apache-Royale . Pour une grande application avec une logique métier complexe, le framework Apache-Royale a été d'une grande aide. Bien qu'une partie de la logique des composants soit différente, elle est suffisamment similaire pour que vous puissiez échanger assez facilement une fois que vous êtes au sommet de la courbe d'apprentissage. Le fait que j'ai pu sauver la plupart de la logique métier et de la structure de l'application a évité à mon projet d'être une réécriture profonde qui aurait pris beaucoup plus de temps. Je dirais que si votre application est grande et complexe, Apache-Royale pourrait être votre meilleure solution pour un port économique.
Nous avons migré deux modules Flex vers AngularJS il y a quelques années. Voici la procédure que nous avons suivie:
Nous avons dû effectuer cette migration car le marketing a décidé que nous devions exécuter une application frontale sur les appareils mobiles sur les deux systèmes d'exploitation: Android et iOS.
Salut, notez simplement qu'Apache Flex n'est pas en fin de vie. Il a encore du sens dans des situations concrètes et continuera d'être un projet Apache valide. Après # flash2020, vous pourrez toujours utiliser vos anciennes applications Flex si vous les encapsulez avec une technologie de wrapper de bureau comme Adobe AIR. C'est ce que font les autres. En revanche, si vous souhaitez migrer, je pense que le moyen le plus simple est d'utiliser Apache Royale ( royale.apache.org < / a>)