En pratique, le problème qui se pose à tout développeur Flex est le même que celui qui se pose à tout développeur tout court : comment éviter que le code ne se transforme en un spaghetti inextricable et devienne impossible à maintenir.
Dans le cas des applications frontales, le problème a été résolu depuis de nombreuses années : il faut autant que faire se peut séparer les données (et leur traitement) de leur représentation. Il y a évidemment des centaines de manières de procéder, mais en l’occurence Adobe nous en propose une, à savoir Cairngorm, présenté comme un framework de développement. Ici il faut entendre framework non pas dans le sens de boite à outils (ce qu’est déjà Flex) mais en tant qu’implémentation de best practices. Les concepteurs de Cairngorm ne disent d’ailleurs pas autre chose (http://www.adobe.com/devnet/flex/articles/cairngorm_pt1.html).
Avant même de d’utiliser ou même de se pencher sur Cairngorm, il est important de penser correctement votre application. C’est pourquoi le premier chapitre du tutorial Cairngorm est consacré aux VO (Value Objects), ce qui peut sembler la base pour un programmeur J2EE, d’autant qu’un VO n’est ni plus ni moins qu’un DTO. Qu’est-ce qu’un VO ? C’est un objet typé qui représente une entitée logique de votre application. Imaginons que vous fassiez une gestion de bibliothèque. A un moment ou à un autre, vous allez afficher les données d’un livre dans un composant XMLX dédié à cet effet. Il faut donc que vous créiez un VO livre dont les champs s’afficheront dans le composant.
public class Book implements ValueObject
{
[Bindable]
public var title:String;
[Bindable]
public var author:String;
[Bindable]
public var publisher:String;
[Bindable]
public var isbn:String;
}
Et le composant associé sera un truc du genre :
<mx:canvas xmlns:mx="http://www.adobe.com/2006/mxml" width="400" height="300">
<mx:label text="Titre : "/>
<mx:label text="Auteur : "/>
<mx:label text="Editeur : "/>
<mx:label text="ISBN :"/>
<mx:textinput text="{book.title}"/>
<mx:textinput text="{book.author}"/>
<mx:textinput text="{book.publisher}"/>
<mx:textinput text="{book.isbn}"/>
</mx:canvas>
où book est une instance de Book.
On remarque l’utilisation du binding sur lequel insistent les concepteurs de Cairngorn. Le binding assure en pratique que l’objet book sera mis à jour en permanence quelles que soient les modifications que l’on effectue avec l’interface.
En pratique les VO servent en fait d’interface entre les données remontées depuis le serveur (et/ou destinées à y être stockées) et les views de Flex. Et le binding assure le liant.
Mais allez-vous me dire : Où y-a-t’il séparation entre les données et les views ? Nous allons y venir. Au sens strict les VO ne sont font pas partie de Cairngorm bien qu’une interface vide encourage vivement à créer des VO. Cairngorm propose donc un premier objet destiné à assurer cette séparation : le ModelLocator.
Stricto sensu, le ModelLocator dans l’API Cairngorm est une interface vide. Ce doit être un singleton, mais c’est à vous de faire en sorte qu’il le soit. Ce qui est important, c’est que le ModelLocator va être une sorte de “sac” contenant tous vos VO. Vous aurez donc un point d’accès unique pour toutes vos données, avec une méthode d’accès unique pour ces données depuis les views. Reprenons l’exemple précédent: le ModelLocator pourrait être
[Bindable]
public class MyModelLocator implements ModelLocator
{
private static var modelLocator : MyModelLocator
public static function getInstance() : MyModelLocator
{
if ( modelLocator == null )
{
modelLocator = new MyModelLocator();
}
return modelLocator;
}
// ArrayCollection of books
public var books : ArrayCollection;
}
On imagine bien une DataGrid qui liste les livres disponibles à partir du champ books du ModelLocator. Quelque chose comme ça :
<mx:DataGrid dataProvider={MyModelLocator.getInstance().books} .....
Et si l’on rajoute dans le ModelLocator un champ selectedItem:Object correspondant au DataGrid.selectedItem, l’exemple de fiche vu plus haut devient :
<mx:canvas xmlns:mx="http://www.adobe.com/2006/mxml" width="400" height="300">
<mx:label text="Titre : "/>
<mx:label text="Auteur : "/>
<mx:label text="Editeur : "/>
<mx:label text="ISBN :"/>
<mx:textinput text="{MyModelLocator.getInstance().selectedIndex.title}"/>
<mx:textinput text="{MyModelLocator.getInstance().selectedIndex.author}"/>
<mx:textinput text="{MyModelLocator.getInstance().selectedIndex.publisher}"/>
<mx:textinput text="{MyModelLocator.getInstance().selectedIndex.isbn}"/>
</mx:canvas>
Evidemment, se pose le problème : comment met-on à jour MyModelLocator.selectedItem à partir de la DataGrid et ce, de manière “propre” ? On peut pour cela utiliser le FrontController. Mais ce sera l’objet du prochain article qui listera les autres fonctionnalités de Cairngorm.



Une remarque :
en mettant tout dans le même sac, cela ne va pas être simple de s’y retrouver quant l’application va grossir et se complexifier.
Il vaut mieux rajouter un ou plusieurs sous niveaux à ton ModelLocator. Exemple :
ModelLocator.getInstance().bookModel.books
Mike
Absolument. Mais c’est aussi ce que je dis : initialement, on peut tout mettre dans le ModelLocator, le mieux comme le pire.
Merci pour cet article, je cherchais justement de la documentation sur Cairngorm et en plus, c’est en français!
Vivement le prochain.
Il n’y aurait pas une petite erreur ??
{MyModelLocator.getInstance().selectedIndex.title} devrait être :
{MyModelLocator.getInstance().selectedItem.title} non ?
bonjour et merci pour ces articles forts utiles !
Ptite question/remarque :
dans l’exemple de MyModelLocator ne faudrait-il pas rendre ‘books’ [Bindable] ?
Bonjour,
Mike pourrais tu développer ton idée de découper le modelLocator en sous partie ?
Merci
Billet yrès intéressant
je suis hors sujet mais je trouve kle design de votre blog très sympathique
bone continuation !