Blog RIA

Voici la grande nouvelle du jour : par la voix d’un de ses évangélisateurs, Adobe annonce officiellement que Flex 3 sera Open Source d’ici la fin de l’année 2007 (voir l’article original en anglais ici: http://www.onflex.org/ted/2007/04/flex-goes-open-source-mpl.php)

Pour l’instant, seuls sont concernés le Flex SDK (MXMLC, COMPC, ASC) , les sources du framework Flex, les librairies de composants et les librairies AS3.

Le plugin Eclipse (FlexBuilder) et le serveur FlexDataServices sont apparemment exclus du lot, de même que le Flash Player et les librairies Flash (mais qui sait…)

La license OpenSource choisie sera MPL (Mozilla Public License)

Sous Flex 2, pour dialoguer entre le client flex et le serveur on peut utiliser  les services suivants :

• Des WebServices
• Des HttpServices (REST) qu’on peut voir comme sont des webservices (très) simplifés.

Adobe propose en plus un service payant, le FDS (Flex Data Services). Si l’on excepte les extensions ColdFusion, on a en fait deux outils fournis avec le FDS

* Le RPC (invocation d’une méthode d’une classe java à distance)
* Le Système de messaging

La documentation étant parfois un peu lacunaire, je m’y suis donc collé et vous ramène tel le messie quelques informations de première main et, je l’espère, plus claires.

Dans ce chapitre nous allons clore notre petite exploration de Cairngorm.

Cairngorm fournit encore un ServiceLocator qui est aussi un singleton. Il permet de regrouper tous les services d’accès distant (WebServices, REST, et autres si on emploie le FDS) et de donner une méthode unique d’accès.
 

A l’heure de la mondialisation, la traduction et la localisation des applications Flex est de plus en plus souvent requise.

Or, s’il s’avère que Flex2 propose un système de localisation basé sur le concept de ResourceBundle. Celui-ci n’est ni pratique à utiliser (car mal documenté), ni souple à déployer. En effet, les ResourceBundle sont compilées et incluses dans le SWF, ce qui impose de créer un fichier SWF applicatif différent pour chaque nouvelle langue.

Pour des applications modestes, ce système de localisation peut s’avérer suffisant, mais pour des applications plus importantes, il faut envisager plutôt un système de localisation dynamique, basé sur des ressources délivrées par le serveur.

Le FrontControler est – de loin – l’objet le plus important de Cairngorm. C’est à vrai dire celui avec lequel Cairngorm peut prétendre être un framework MVC. Revenons à la problématique initiale : comment séparer les données (et leur traitement) des views ? Nous avons vu avec le ModelLocator comment faire en sorte que les views soient « alimentées ». Se pose maintenant le problème inverse : comment modifier les données, voire faire des traitements en fonction des actions utilisateurs (ce que les concepteurs de Cairngorm appellent des gestures) ?