Prendre un Café

Pour les besoins du boulot, j'ai du me mettre à Flex, le framework d'Adobe orienté RIA en Flash.

Je pensais que mon passé de flasheur m'aiderait à monter rapidement en compétence sur cette techno, ben non : c'est tout à fait autre chose que ce que je connaissais de l'IDE traditionnel, dont je m'étais arrêté à la version 8. Avec Flex on a affaire à un framework complet de génération d'interfaces riches basées sur l'emploi de composants décrits et paramétrés en XML et de la dernière mouture du langage ActionScript en version 3. Quelques exemples d'applications réalisées avec Flex sont disponibles, et pour certaines, ça en jette carrément.

Le langage MXML

La description des interfaces s'opère au moyen du langage MXML^[1], basé sur XML un peu comme ce que proposent XUL ou XAML ou même XHTML (qui reste une implémentation particulière et standardisée d'XML). Deux types principaux de composants sont disponibles : les conteneurs (boîtes, panneaux, fenêtres, etc.) et les éléments de contrôle (champs texte, listes, datagrids, tree, etc.)

Le nombre de conteneurs et de contrôles est impressionnant, on se prend à rêver de la même richesse en HTML ^[2]. La plupart des composants sont visibles sur l'explorateur de composants Flex, sur le site d'Adobe. Et le meilleur reste sans doute à venir quand on voit le catalogue de composants supplémentaires open source comme ceux du projet FlexLib...

Le format généré après compilation d'un ensemble de fichiers MXML constituant une application Flex est le SWF, le format natif d'Adobe Flash, lisible par tout bon Flash Player 9 qui se respecte, implanté sur plus de 80% du parc machines desktop mondial d'après les dernières statistiques disponibles sur le site d'Adobe.

Voila un exemple de code MXML décrivant l'interface d'une application simpliste :

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
   <mx:Panel title="Dire bonjour" x="10" y="10" layout="absolute" width="303">
      <mx:TextInput id="firstname" x="10" y="10"/>
      <mx:Button label="Dire bonjour" click="result.text='Bonjour, '+firstname.text" x="178" y="10"/>
      <mx:Label id="result" x="10" y="40" width="265"/>
   </mx:Panel>
</mx:Application>

Le code est assez parlant, mais voici quelques éléments significatifs :

• Le conteneur principal de l'application déclare l'espace de noms mx, ce qui nous permettra d'utiliser les composants natifs de Flex
• L'application déclare un conteneur sous la forme d'un Panel contenant trois contrôles :
  • un InputText, champs de saisie textuelle
  • un Button, un bouton d'action
  • un Label, un champs de texte potentiellement dynamique
• Chaque élément peut se voir nanti d'un attribut id qui doit être unique si renseigné ; il permet de référencer facilement un élément de l'arbre DOM
• La gestion des évènements peut se faire directement en MXML : ici, quand on clique sur le bouton, le contenu texte du label est modifié en fonction de la valeur textuelle du champs de saisie.

Style et mise en forme

Dans l'exemple précédent, on voit que les styles sont appliqués sous forme d'attributs XML. C'est une solution pratique à court terme mais qui peut rapidement s'avérer problématique à maintenir dès que votre application grossit. Aussi, pour séparer la couche de présentation de la description des contenus, tout comme en HTML, Flex permet l'utilisation de feuilles de styles CSS embarquées ou externalisées. Beaucoup de propriétés CSS ont du être créées ou adaptées aux spécificités du balisage MXML et des composants proposés, mais le résultat est une grande souplesse d'utilisation et une large palette de mise en forme disponible. Pour preuve, un petit tour du côté de l'explorateur de styles Flex s'impose.

Le langage ActionScript 3

ActionScript 3 est l'évolution logique des précédentes versions, étendant le périmètre fonctionnel et accentuant son caractère professionnel, notamment dans l'implémentation objet, les types natifs et l'organisation en packages des différents objets de programmation.

Composants personnalisés

Une des grandes forces de Flex à mes yeux est la simplicité avec laquelle on peut créer ses propres composants en héritant de composants basiques préexistants et de les manipuler via son propre espace de noms. Par exemple, la création d'un composant dérivé d'un formulaire présentant un champs de login/mot de passe donne à peu près ceci :

<?xml version="1.0" encoding="utf-8"?>
<mx:Form xmlns:mx="http://www.adobe.com/2006/mxml" width="280" height="105">
   <mx:FormItem label="Login">
      <mx:TextInput id="username"/>
   </mx:FormItem>
   <mx:FormItem label="Mot de passe">
      <mx:TextInput id="password" displayAsPassword="true"/>
   </mx:FormItem>
   <mx:FormItem>
      <mx:Button label="Connexion"/>
   </mx:FormItem>
</mx:Form>

Si on nomme notre fichier de composant LoginForm.mxml et qu'on le stocke dans le répertoire ./components de notre projet Flex, on va pouvoir l'utiliser de la façon suivante dans une application :

<?xml version="1.0" encoding="utf-8"?>
<mx:Application 
   xmlns:mx="http://www.adobe.com/2006/mxml" 
   xmlns:niko="components.*"
   layout="absolute">
   <mx:Panel title="Connexion">
      <niko:LoginForm id="loginform"/>
   </mx:Panel>
</mx:Application>

On a déclaré un nouvel espace de noms, ici niko (mais on aurait pu mettre ce qu'on veut) pointant vers les fichiers sous le répertoire components du projet. Simple, non ? En tout cas, cela devient un jeu d'enfant de produire des composants réutilisables.

Le nerf de la guerre, l'accès aux données distantes

Flex propose trois modes d'accès aux données distantes, par le biais de trois composants :

• L'objet HTTPService, comme son nom l'indique, permet d'effectuer des requêtes HTTP sur une url et d'en récupérer la réponse. Un objet bien pratique quand on veut s'interfacer avec une architecture REST, par exemple.
• L'objet WebService permet de s'interfacer avec un webservice au format WSDL via SOAP. Quand on dispose de tels service, c'est un plaisir de se baser dessus depuis Flex puisqu'on a qu'à réferencer les méthodes à utiliser et les déclencher depuis leur référence.
• Mais l'objet de loin le plus intéressant à mes yeux est RemoteObject, implémentation du protocole RPC dans Flex, pendant Flash/ActionScript du RMI en Java. Comme je fais peu de Java, j'ai tendance à plutôt utiliser AMFPHP^[3] pour publier mes services en utilisant PHP. Un très bon tuto de mise en oeuvre du couple AMFPHP/Flex se chargera d'illustrer le concept plus efficacement que je ne le fais ici.

FlexBuilder

Adobe propose un IDE dédié à la réalisation d'applications Flex, FlexBuilder. Cet outil, basé sur le célebrissime Eclipse, permet de disposer d'un environnement complet de développement comprenant entre autres un éditeur de code (MXML en mode source/wysiwyg, ActionScript, CSS, etc.), un débogueur avancé à la Java, un gestionnaire de projets, la compilation automatique et surtout un accès à l'immense catalogue des plugins Eclipse. D'ailleurs, FlexBuilder est également disponible sous la forme d'un plugin à installer sur une instance d'Eclipse existante : de quoi travailler sur vos projets Flex/PHP de façon centralisée, par exemple.

Inconvénient majeur de cet outil, il est payant. Et coûte relativement cher, puisque proposé aux alentours de 500€. Néanmoins, le SDK de Flex étant gratuit, vous pouvez tout à fait vous passer de FlexBuilder et compiler vos applications à la main. Une bonne nouvelle ne venant jamais seule, Adobe a décidé de publier la prochaine mouture du framework sous licence libre ^[4], aussi nous devrions voir fleurir des alternatives à FlexBuilder et assister à un taux d'adoption plus conséquent de la technologie.

Organisation du code, frameworks

Au vu de l'étendue fonctionnelle de Flex et des différents formats de fichiers mis en oeuvre ainsi que de leurs interactions potentielles, il est clair que maintenir la moindre petite application peut vite relever du cauchemar les développements avançant. Pour faire face à cette problématique, Adobe propose un surframework du nom de Cairngorm mettant en oeuvre les bonnes pratiques d'architecture logicielle en implémentant le motif de conception MVC bien connu des utilisateurs de frameworks de développement rapide orientés web.

Même si le projet semble extrêmement intéressant, je n'ai pas encore pour l'heure pu jouer avec.

Conclusion

Pour l'heure et après avoir pas mal galéré tâtonné avec l'outil au début, je dois reconnaître maintenant et avec un peu de recul que c'est assez efficace. C'est relativement déstabilisant pour quelqu'un qui comme moi avait l'habitude de l'IDE Flash Authoring classique, mais au final FlexBuilder semble beaucoup plus sérieux pour tout ce qui concerne la programmation et l'organisation des fichiers (Eclipse oblige.) Même le templating y gagne à mon sens, mais par contre impossible de faire de la création graphique avancée directement dans FlexBuilder, l'outil n'est clairement pas l'ami des infographistes de vocation.

Pour enfoncer le clou, j'ai pu comparer l'utilisation de Flex et de XUL, ayant enchaîné deux projets coup sur coup les mettant en oeuvre. L'excellente documentation de Flex et la richesse des outils gravitant autour de la techno font que pour l'heure Flex me semble l'un des meilleurs choix pour développer une RIA, si l'on écarte le couple HTML/Ajax qui garde une toujours une place de choix dans mon arsenal webdeuzéroesque