Tutorial Cairngorm
19 December 2007 par you_gLorsque plusieurs développeurs décident de travailler en collaboration pour créer une application riche en Flex ou Air, un gros problème se pose: comment éviter que le code ne devienne illisible pour les autres et, du coup, impossible à maintenir ?
Il existe plusieurs manières de procéder pour pallier à ce problème mais dans cet article nous nous attarderons sur la solution proposée par les consultants d’Adobe Consulting, en l’occurrence Cairngorm que vous pouvez télécharger à cette adresse: http://labs.adobe.com/wiki/index.php/Cairngorm
Cairngorm est un framework architectural qui va permettre aux développeurs de bâtir le squelette de leur application. On dit de Cairngorm que c’est une micro architecture car il regroupe plusieurs modèles de conceptions (MVC, FrontController, Command, Singleton…).
Contrairement aux modèles de conceptions qui sont là pour résoudre un problème précis, la composition de patterns tel que Cairngorm va nous permettre de résoudre des problèmes de conceptions récurrents dans le développement de notre application:
- Récupérer les événements de l’utilisateur
- Encapsuler la logique métier et les interactions avec le serveur
- Gérer et représenter les données de l’application coté client
Maintenant que nous savons ce qu’est Cairngorm, nous allons maintenant nous attaquer à la création de notre première RIA. Pour la réalisation de ce tutorial, vous aurez besoin de:
Nous allons pour ce tutorial créer un petit carnet d’adresse qui après ajout d’un contact, l’affichera dans la liste de contacts.
Dans un premier temps, je vous invite à créer un projet Flex et d’y ajouter les 6 répertoires suivants dans src:
- Business
- Command
- Control
- Model
- View
- VO
Voila à quoi ressemblera le squelette de l’application
Ensuite, il faut ajouter le fichier Cairngorm.swc dans le « library path » de votre projet Flex. Pour cela, faites un clique droit sur le projet, cliquez sur « properties », sélectionnez le « Flex Build Path », et dans l’onglet « Library Path », ajoutez le fichier SWC.
Maintenant, on peut commencer!
Les VO
Avant de commencer le développement de l’application, il faut dans un premier temps créer les VO ou Value Object (parfois appelés DTO, correspondant à Data Transfert Object).
Les VO sont des objets typés qui représentent une entité logique de notre application. Dans le cas de notre carnet d’adresse, nous devons créer un VO contact qui contiendra toutes les informations relatives à l’enregistrement d’un contact dans la base de données.
C’est ce même VO qui va nous donc nous permettre d’effectuer l’interface entre les données du serveur et les vues flex sur lesquelles seront affichées les informations.
Maintenant que l’on sait comment gérer les données de l’application, voyons comment ces VO vont être utilisés dans notre application.
Le ModelLocator
Le ModelLocator de Cairngorm propose d’encapsuler les données du client dans une structure. C’est cet objet qui va permettre d’assurer la séparation entre les données et les vues.
Le ModelLocator est un singleton qui sera, pour l’application, une sorte de « grosse variable globale» contenant tous nos VO. Grâce à ce ModelLocator, on aura toujours un point d’accès unique sur toutes nos données depuis les vues.
C’est donc grâce à ce ModelLocator que les données des différentes vues de l’application seront affichées. De plus, le fait qu’il soit « Bindable », offre l’avantage de lier les données de notre model aux composants de notre vue. Ce qui signifie que si les données sont mises à jour dans le model, cela sera immédiatement répercuté dans les vues sans que l’on est rien à faire. C’est pas génial ça ?
Les Vues
Notre vue contiendra tout simplement un composant datagrid qui permettra d’afficher la liste de nos contacts ainsi qu’un formulaire pour ajouter un contact dans notre carnet d’adresse. Le dataprovider de notre datagrid sera directement connecté à la collection de contacts contenu dans notre modèle qui sera mis à jour à chaque ajout de contact.
Vous noterez dans la fonction addContact (), la présence du CairngormEventDispatcher qui a pour but d’envoyer l’événement qui sera à l’origine de l’exécution de la commande.
Maintenant se pose la question: comment met-on à jour les données du ModelLocator ? Pour cela nous utiliserons le FrontContoller.
Le FrontController
Le FrontController est un modèle de conception composé du pattern MVC et du pattern Commande.
Comment fonctionne-t-il ? L’idée est simple: lorsqu’un utilisateur effectue une action, on émet un événement. Ce dernier sera capté par le FrontController et, pour chaque événement , est associé une commande à effectuer.
Il faut donc dans un premier temps identifier tout les événements de notre application. Dans le cas de notre carnet d’adresse, il s’agira de l’ajout d’un contact dans notre liste. Si cet événement est détecté par notre FrontController, la commande addContactCommand sera exécutée.
Les commandes
Une commande Cairngorm doit implémenter l’interface Command, c’est-à-dire implémenter la fonction execute(event : CairngormEvent) : void qui est appelée par le FrontController.
Notre commande aura pour mission de commander l’ajout d’un contact dans notre carnet d’adresse. Pour cela elle délègue l’appel serveur sur la classe Delegate. Le but de notre commande est de récupérer les données à envoyer aux serveurs via le delegate.
Dans notre cas les données à récupérées sont les informations du contact présent dans le formulaire et que l’on obtiendra grâce à l’instance de notre événement AddContactEvent.
Les delegates
Comme présenté précédemment, les delegates seront chargés d’encapsuler les appels aux méthodes des services distants. Par exemple, effectuer l’ajout du contact dans notre base de données.
Pour ce faire, il fait appel à un ServiceLocator qui va nous permettre de localiser le service distant et de l’appeler.
(N’ayant pas la possibilité de vous présenter l’accès aux services distants, les bouts de codes correspondants à cette partie seront mis en commentaire. Pour notre exemple, nous simulerons l’accès au remote service result).
Il existe différents types de services distants. On peut citer: WebServices, REST, RemoteObject ….
La définition des ServiceLocator se fait à travers un fichier mxml où sont spécifiés les différents objets distants ainsi que leur source.
Le résultat du service sera récupéré dans la fonction onResult de la commande. Et c’est également à ce moment que l’on mettra à jour la liste des contacts qui sera automatiquement mis à jour dans le datagrid de notre carnet d’adresse.
Après avoir réalisé toutes les étapes, voila à quoi ressemble la structure finale de votre projet Cairngorm.
Vous pouvez télécharger les sources de l'application ici: Source Carnet Adresse
Conclusion
Et voila, j’espère que ce tutorial vous a été utile et que grâce à lui vous avez pu comprendre le fonctionnement du framework Cairngorm qui au premier abord ne semble pas si simple.
N’oubliez pas, Cairngorm n’est pas une nécessité. Pour les projets de petite taille, mieux vaut s’en passer. Cairngorm trouve toute son utilité lorsque les projets sont conséquents et lorsque l’on souhaite réaliser un code propre, bien structuré et maintenable.
Il faut également avoir en tête que Cairngorm n’est pas le seul framework architectural existant pour le développement Flex. Il en existe d’autre tel que PureMVC (www.pureMVC.org) qui à l’avantage d’être plus évolutif que Cairngorm…
8 June 2008 à 16:12
Il y a quelque chose que je ne comprend pas…
Il s’agit de la fonction execute de la classe AddContactCommand. (voir image de la partie “Les commandes” )
public function execute(event:CairgormEvent):void
{
var delegate : AddContactDelegate = new AddContactDelegate (this);
var addContactEvent : AddContactEvent = new AddContactEvent (event);
delegate.UpdateContact(addContactEvent.contactVO);
}
La fonction execute prend en entrée un CairngormEvent qui ne connait pas nos ContatVO.
En construisant un AddContactEvent via un CairgormEvent, aucun ContactVO n’est donnée au constructeur de l’AddContactEvent. On ne pourra donc pas faire le addContactEvent.contactVO (et de toutes manières ça ne compile pas apparemment)
Je pensait solutionner le problème en implémentant mon execute de cette manière :
public function execute(event : AddContactEvent ):void
{
var delegate : AddContactDelegate = new AddContactDelegate (this);
var addContactEvent : AddContactEvent = new AddContactEvent (event.contactVO);
delegate.UpdateContact(addContactEvent.contactVO);
}
Le problème est que cela ne semble pas possible car il n’y a aucune signature de execute compatible avec cela, dans ICommand…
Est-ce que vous avez rencontré ce problème ?!
24 June 2008 à 13:21
Bonjour,
Tout d’abord je tiens à vous remercier pour ce tutorial qui m’a permis de lutter contre l’unalphabétisme en Cairngorm :), pourtant j’ai quelques soucis :
En fait dans la méthode execute de la classe addContactCommand à part ce que Mr. LEONARDO a signalé j’ai pas compris cette instruction : var addContactEvent AddContactEvent : AddContactEvent = AddContactEvent(event);
En fait d’après ce que j’ai compirs -sachant que je suis un débutant en ActionScript- c’est que vous avez déclaré une variable de type AddContactEvent et que vous lui avez affecté la valeur retourné par AddContactEvent(event), sachant que AddContactEvent est un constructeur et non pas une fonction.
Et merci encore pour ce tutorial.
24 June 2008 à 13:34
Juste une dernière question, s’il vous plais je voudrais savoir la signification du paramètre (event : *=null).
merci.
25 June 2008 à 18:03
Bonjour,
Je pense que event : * signifie que cette fonction peut prendre un parametre d’un type non determine.
Quand au = null, c’est un valeur d’initialisation de la variable qui sera initalise a null si aucun parametre n’est passe a la fonction.
27 February 2009 à 11:43
Tutoriel sympa qui offre une alternative à celui proposé par Adobe : Introducing Cairngorm (http://www.adobe.com/devnet/flex/articles/introducing_cairngorm.html)
@Leornardo : le VO est connu par l’Event au moment de la création de l’évent dans la vue. Concernant le paramètre d’execute() de type Cairngorm event, il s’agit là d’une des particularités du framework, obligeant à caster son event dans le bon type.
@Ziad : var addContactEvent AddContactEvent : AddContactEvent = AddContactEvent(event); signifie qu’on va caster l’event dans son bon type AddContactEvent(event) et l’associer à une variable comme tu l’a compris.