• › Connexion
  • Blog RIA
Section separator

Catégories

  • Annonces
  • Concepts et Usages
  • Événements
  • Général
  • Notes Techniques
  • Références
Adobe EMEA Silver Solution Partner Section separator

Abonnement

  • RSS Articles Articles (RSS)
  • RSS Articles Commentaires (RSS)
  • RSS mail Articles (Email)
  • Populaires
  • Récents
  • Commentaires
  • Retour sur le Visual Decision Forum’11 ! (vu 4 111 fois)
  • De l’art d’auto-compléter (en interaction clavier/souris) (vu 1 414 fois)
  • Flex 4 : Tour d’horizon sur les ItemRenderers (vu 1 391 fois)
  • Flex est mort, vive Flex ! (vu 1 234 fois)
  • Internationalisation & Localisation : Les nouveautés Flex 4.5 (vu 1 176 fois)
  • Sortie de Kalileo 2.4
  • TestRail : on l’a testé, on l’a adopté !
  • DB2 à la page dans Hibernate 4
  • Parsley fait peau neuve
  • Apache Flex Logo Contest : il n’en restera qu’un pour les gouverner tous !
  • Sphaxslayer dans Contest logo Apache Flex : Nos propositions
  • Anonyme dans Contest logo Apache Flex : Nos propositions
  • Pbergsma dans Contest logo Apache Flex : Nos propositions
  • Liens informatiques du mois – janvier 2012 | Gestion de projet et développement informatique dans Flex est mort, vive Flex !
  • Florian Fesseler dans Flexmojos : Quick compile mode

Auteurs

  • Alexis Kartmann (11)
  • Antoine Gehl (4)
  • Benoit Kogut-Kubiak (2)
  • Cyril Daloz (10)
  • Daniel Pesic (6)
  • Delphine Estebanez (4)
  • Fadi Mansour (3)
  • Florent Hirsch (1)
  • Florian Fesseler (13)
  • Gaétane Stavaux (3)
  • Guillaume Mignard (4)
  • Java Team (1)
  • Julien Revel (22)
  • Mahmoud Ramadan (1)
  • Matthieu Jobert (1)
  • Morgan Bruneau (1)
  • Stéphane Guyot (1)
  • Stéphane Koëth (2)
  • Thomas de Verdière (1)
  • Yann Graufogel (3)
Section separator

Tags

Adobe Business Exchange Adobe MAX AIR AMF AS3 Cairngorm Corporate Data Visualization Flex Framework JAVA Kap Inspect Kap Lab LCDS LiveCycle Mobile MVC PureMVC QA Reporting RIA RTMP Spark UX Web 2.0
Section separator

Archives

  • avril 2012 (1)
  • février 2012 (3)
  • janvier 2012 (5)
  • décembre 2011 (1)
  • novembre 2011 (2)
  • octobre 2011 (4)
  • août 2011 (2)
  • juillet 2011 (5)
  • juin 2011 (4)
  • mai 2011 (1)
  • mars 2011 (1)
  • janvier 2011 (1)
  • décembre 2010 (1)
  • novembre 2010 (3)
  • juin 2010 (1)
  • mars 2010 (1)
  • février 2010 (1)
  • décembre 2009 (2)
  • novembre 2009 (1)
  • octobre 2009 (3)
  • septembre 2009 (1)
  • août 2009 (1)
  • avril 2009 (2)
  • février 2009 (1)
  • janvier 2009 (3)
  • décembre 2008 (4)
  • novembre 2008 (2)
  • octobre 2008 (2)
  • septembre 2008 (2)
  • août 2008 (1)
  • juin 2008 (1)
  • avril 2008 (4)
  • mars 2008 (3)
  • février 2008 (2)
  • janvier 2008 (1)
  • décembre 2007 (3)
  • novembre 2007 (1)
  • septembre 2007 (1)
  • juillet 2007 (1)
  • juin 2007 (1)
  • mai 2007 (3)
  • avril 2007 (8)
  • mars 2007 (2)
  • février 2007 (1)

Marque-pages

  • Adobe Blogs
  • Adobe Developer Connection
  • Adobe Evangelists
  • Adobe Flex Tutorials (FR)
  • Code moi un mouton
Section separator

Kap IT

  • Site Web
  • Blog RIA
  • Kap Lab - Composants Flex
  • Kap Lab - Plugins Confluence

Blog RIA

Veille, Recherche et Développement RIA Flex-AS3-LiveCycle

Utiliser le framework Cairngorm pour Flex 2 (1/4)

Par Julien RevelgravatarFermerAuteur : Julien Revel Email : julien.revel@kapit.fr
Site : http://www.kapit.fr
A propos : Voir les autres billets de l'auteur (22)
, publié le 11 avril 2007

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.

Catégories: Notes Techniques
Mots-clefs :Cairngorm, Flex, RIA
  • Mike

    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

  • jrevel

    Absolument. Mais c’est aussi ce que je dis : initialement, on peut tout mettre dans le ModelLocator, le mieux comme le pire.

  • Florian F.

    Merci pour cet article, je cherchais justement de la documentation sur Cairngorm et en plus, c’est en français!

    Vivement le prochain.

  • mruellan

    Il n’y aurait pas une petite erreur ??

    {MyModelLocator.getInstance().selectedIndex.title} devrait être :
    {MyModelLocator.getInstance().selectedItem.title} non ?

  • http://lafabrick.com/blog erick

    bonjour et merci pour ces articles forts utiles !

    Ptite question/remarque :
    dans l’exemple de MyModelLocator ne faudrait-il pas rendre ‘books’ [Bindable] ?

  • Tibetoine

    Bonjour,

    Mike pourrais tu développer ton idée de découper le modelLocator en sous partie ?

    Merci

  • http://lavoux.com florian

    Billet yrès intéressant ;) je suis hors sujet mais je trouve kle design de votre blog très sympathique :) bone continuation !

Article précédent
Article suivant
 
Haut de page

Copyright © 2009 Kap IT - Blog RIA - Kap Lab

Motorisé par Wordpress - Thème avec YAML par Kap IT