Blog RIA.do.be

En annonçant Cairngorm3 l’automne dernier, Adobe a cessé d’occuper le terrain des frameworks techniques pour celui des guides, des librairies et des bonnes pratiques.

Même si cet ensemble répond aux besoins de construction d’applications d’entreprise modulaires et maintenables, il manque le maillon du modèle d’architecture applicatif unifié, absent des guides. A ce stade de réflexion, on pense à l’approche Model-Vue-Contrôleur mais on n’en trouvera trace. On trouvera au lieu de cela une structure à couches applicatives telle qu’elles se sont généralisées dans les applications du côté serveur.
Pour retrouver une approche MVC, on peut chercher du côté des frameworks Parsley ou Swiz, mentionnés comme compléments à Cairngorm3. On voit ainsi Cairngorm2 sombrer dans l’oubli tellement il aura été critiqué, et les autres alternatives comme pureMVC, Mate, etc. continuer à exister mais de manière marginale.

Evolution naturelle diront certains, mais pourquoi se compliquer la vie avec des guides, des frameworks externes, et des concepts comme l’IoC alors que ces solutions marginales mais unifiées répondent aux besoins ?

Nous étions quelques personnes de Kap IT présentes à un séminaire très technique “Tomcat Expert series” d’une demi-journée présenté par Filip Hanik de SpringSource, la “Tomcat-Company” (Filip est un des principaux contributeurs du projet open source Apache Tomcat).

La présentation de Filip voulait démontrer que Tomcat est une alternative viable en production, que ce soit sur le plan technique ou économique.
 

L’arrivée cet été du framework MVC Cairngorm dans le giron du site open source Adobe a été accompagnée d’un mouvement sur la toile assez bruyant et critique du framework en lui-même.

Examinons les deux principaux reproches récurrents :

• Le ModelLocator comme container de variables globales fourre-tout
• Le couplage fort du binding entre le ModelLocator et la vue

L’objet de ce billet est de pointer du doigt ce qui nous semble poser le plus de souci dans l’implémentation de Cairngorm et d’exposer le chainon manquant. Le périmètre concerne les applications d’entreprises dont les fonctionalités sont destinées à évoluer.
 

Cet été, Adobe a mis en ligne des update mineures mais significatives de plusieurs éléments de la chaîne Flex/lcds, et aussi beaucoup communiqué par l’intermédiaire des bloggeurs sur les prochaines versions majeures.
 

Ca remue en ce moment du côté LCDS :

1/ LCDS est passé en 2.6 beta publique la semaine dernière. Voici les points marquants de cette version :

• des corrections de bugs et améliorations de performances
• l’usage des NIO Java se généralise en dehors du périmètre RTMP. Ce ne peut qu’être une bonne nouvelle pour la montée en charge par serveur. Attention toutefois si vous avez déjà codé des applications partageant la session http et la session Flex côté serveur.
• La documentation aussi est plus complète sur l’usage des protocoles.
• Le DataManagement s’étoffe de la pagination, d’un cache AIR implémenté avec SQLLite, et d’un meilleur support de l’héritage lors de conversions java <> AS3 <> Java.
• on trouvera dans la version téléchargeable une application d’administration en Flex (ds-console) très utile pour vérifier en phase de développement que nos services distants ont été paramétrés et initialisés correctement.

Pour en savoir plus, en anglais, le blog de Damon Cooper