Pourquoi utiliser une XSD?

Pour ma part, ces quelques raisons (et pour vous certainement plein d’autres raisons)

• Elle valide vos XML : parce que vous définissez en amont la structure de vos fichiers, une définition XSD permet de les valider;
• Parce que vous avez besoin de plusieurs écritures différentes d’un même jeu de donnés;
• Parce que, comme tout bon dèv, vous êtes fainéant…
• …et le fait que le programme valide tout et fait tout, tout seul, en suivant des règles normées ça vous va bien.
• Ca fait toujours bien d’avoir des fichiers XSD dans vos sources : ça envoie de la rosette, et vous pouvez vous la péter grave.
• …

Dans un usage Flex, l’objectif serait de pouvoir transformer nos objets AS en XML, et l’inverse, via les schémas de définitions. Ça tombe bien ! C’est ce qu’on va faire.

Où tu te caches XSD ?!

Dans la plupart des langages, nous avons la possibilité de discuter avec notre serveur en utilisant le protocole SOAP, basé sur XML. En utilisant ce protocole, nos objets sont “transformés” en XML, et transmis vers notre serveur. L’opération inverse existe lors de réception de données.
Mais pourquoi je vous parle de ça? Tout simplement parce que tout langage faisant du SOAP (ou du web service), à besoin de valider et de convertir de manière automatique les objets. Et je vous le donne en mille, ce sont les définitions XSD qui entrent en jeux (souvent ).

La mécanique XSD est utilisée, en interne dans Flex, pour l’encodage et le décodage d’objet SOAP ou WSDL. Ces classes, exclues du framework (vous n’y avez pas accès directement avec l’autocomplétion), se trouvent dans le package mx.rpc.xml.*.

Car vous allez le voir, il est relativement simple d’utiliser cette partie de Flex, pour un usage personnalisé du XML, en dehors du contexte RPC.

Des groupes, des geeks, des bidules

Donc c’est parti pour l’exemple. Je ne me casse pas la tête, et vous propose un biniou qui aura 3 éléments : des groupes, des gens (geek forcement), et des bidules… Je n’étais pas inspiré sur le 3ème éléments, mais il m’en fallait un….

XML et la définition XSD

Nous avons une infinité d’écriture XML possible, comme celle-ci :

<?xml version="1.0" encoding="UTF-8"?>
<groups>
    <group>
        <groupName>klingons</groupName>
        <geeks>
            <geek>
                <firstName>francis</firstName>
                <stuffs>
                    <stuff>
                        <name>mac</name>
                  </stuff>
                   <stuff>
                        <name>Flex</name>
                    </stuff>
                </stuffs>
            </geek>
        </geeks>
    </group>

    <group>
        ...
</groups>

Ou celle là :

<?xml version="1.0" encoding="UTF-8"?>
<groups>
    <group groupName="klingons">
        <geeks>
            <geek firstName="francis">
                <stuffs>
                    <stuff name="mac" />
                    <stuff name="Flex" />
                </stuffs>
            </geek>
            <geek firstName="roger">
                <stuffs>
                    <stuff name="pc" />
                    <stuff name="photoshop" />
                </stuffs>
            </geek>
        </geeks>
    </group>

    <group>
        ...
</groups>

Ou un mélange à votre sauce, vous faites bien comme vous voulez !

Nous allons donc écrire notre XSD, qui va définir le XML définit ci-dessus, celui qui utilise pleins d’attributs. Je prend celui là parce que la sortie XML est moins longue…. et mon article gagnera quelques lignes…. En ce moment mes articles sont un peu trop pépère… Ca doit être l’approche des fêtes.

Bref !

Le but est de réaliser une XSD la plus complète possible, ou toutes les parties sont typées (SimpleType ou ComplexeType). C’est important pour la suite, car chaque type sera “mappé” avec la classe ActionScript qui lui correspond.

Dans notre exemple, nous avons 3 collections (groups geeks, stuffs) et 3 éléments (group, geek, stuff)… D’accord je ne me suis pas foulé les doigts sur ce coup là !

Le schéma XSD n’est finalement qu’un fichier XML standard :

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    targetNamespace="schemas/geeks"
    xmlns="schemas/geeks">

    <xsd:element name="groups" type="groupsCollectionType" />

</xsd:schema>

L’élément principale, le noeud “<groups>”, est la base de notre schéma. Le type correspondant va s’appeler groupsCollectionType.

La version actionScript de ce type groupsCollectionType serait un Array ou ArrayCollection (ou tout autre type de collection d’objet).
groupsCollectionType est une séquence, un réceptacle de 0 à n éléments de type group (le nombre d’instances minimum et maximun est défini par minOccurs et maxOccurs).

<xsd:complexType name="groupsCollectionType" mixed="true">
    <xsd:sequence>
        <xsd:element name="group" type="groupType"
            maxOccurs="unbounded" minOccurs="0" />
    </xsd:sequence>
</xsd:complexType>

Le type group est composé comme suit :

<xsd:complexType name="groupType" mixed="true">
    <xsd:sequence>
        <xsd:element name="geeks" type="geeksCollectionType"
            minOccurs="0" maxOccurs="1"  />
    </xsd:sequence>

    <xsd:attribute name="groupName" use="required" type="xsd:string" />

</xsd:complexType>

On retrouve le noeud geeks, unique, mais non obligatoire (minOccurs= »0″ maxOccurs= »1″), qui sera défini dans un type geeksCollectionType de la même manière que groupsCollectionType.
Les attributs du noeud sont placé à la suite de la séquence d’éléments. Ils peuvent être requis ou optionnel, définit par l’attribut use. On peut aussi le définir “prohibited” même si je ne vois pas vraiment l’intérêt…

Et on continue comme cela, en rentrant en profondeur dans nos différent objets. La syntaxe n’est pas compliquée, il suffit de se pencher un peu sur les spécifications de la W3C.

Vous trouverez ici la XSD complète de notre exemple.

Côté ActionScript

Nous avons besoin de 3 objets, qui correspondent aux 3 types d’éléments de notre XML : des groupes de Geek, des Geeks, des Stuffs.

Là, rien de plus basique.

• La classe GeekGroup : avec une propriété groupName, et une collection geeks (les geeks membres du groupe)
• La classe Geek : avec une propriété firstName, et une collection stuffs (les bidules du geek)
• La classe Stuff : avec une propriété name, le nom du bidule

Vous vous rendez compte, tout d’un coup, que je ne vous ai absolument rien appris dans ce paragraphe. Passons à la suite.

Les classes de gestion XSD

Nous avons une XSD et des objets AS prêts à être convertis. Regardons de plus près les classes exclues dont nous avons besoin:

• mx.rpc.xml.SchemaTypeRegistry : cette classe est une sorte de dictionnaire, ou l’on référence les différents types du schéma XSD, avec leurs classes actionScript associées.
• mx.rpc.xml.XMLDecoder : la classe qui permet de décoder une source XML, en suivant la XSD, vers un object typé actionScript.
• mx.rpc.xml.XMLEncoder : la classe qui permet d’encoder un objet AS en un fichier XML, en suivant la définition XSD.
• mx.rpc.xml.Schema : la classe contenant le schema XSD chargé.
• mx.rpc.xml.SchemaManager : point central du système, cette classe est utilisée par l’encodeur et le décodeur. Elle possède une référence au schéma (elle peut d’ailleurs contenir plusieurs schéma XSD), et utilise les références de classes et de type XSD enregistrés dans mx.rpc.xml.SchemaTypeRegistry.

Votre object en XML, via XSD

Dans un premier temps, il nous faut charger la définition XSD via un URLLoader :

var urlLoader : URLLoader = new URLLoader();
urlLoader.addEventListener( Event.COMPLETE, onLoadXsdComplete );
urlLoader.load( new URLRequest( "geek.xsd" ) );	

A la réception de la XSD, nous initialisons la classe Schema et le SchemaManager :

var _schema:Schema = new Schema();
var _schemaManager:SchemaManager = new SchemaManager();

_schema.xml = XML( urlLoader.data );
_schemaManager.addSchema( _schema );

Nous ajoutons la référence du manager de schéma dans nos objets d’encodage/décodage :

var _xmlDecoder:XMLDecoder = new XMLDecoder();
var _xmlEncoder:XMLEncoder = new XMLEncoder();

_xmlDecoder.schemaManager = _schemaManager;
_xmlEncoder.schemaManager = _schemaManager;

Ensuite, nous référençons les types contenus dans la XSD, avec les classes AS correspondantes :

var _schemaTypeRegistry : SchemaTypeRegistry;
_schemaTypeRegistry = SchemaTypeRegistry.getInstance();

_schemaTypeRegistry.registerClass(
    new QName(_schema.targetNamespace.uri, "groupsCollectionType"), ArrayCollection);
_schemaTypeRegistry.registerClass(
    new QName(_schema.targetNamespace.uri, "groupType"), GeekGroup);

_schemaTypeRegistry.registerClass(
    new QName(_schema.targetNamespace.uri, "geeksCollectionType"), ArrayCollection);
_schemaTypeRegistry.registerClass(
    new QName(_schema.targetNamespace.uri, "geekType"), Geek);

_schemaTypeRegistry.registerClass(
    new QName(_schema.targetNamespace.uri, "stuffCollectionType"), ArrayCollection);
_schemaTypeRegistry.registerClass(
    new QName(_schema.targetNamespace.uri, "stuffType"), Stuff);

Enfin, nous récupérons notre XML tout bien valide, image de l’objet targetObject, via l’encodeur XML (il faut préciser le nom du noeud “root” de la XSD) :

var xmlList : XMLList = _xmlEncoder.encode( targetObject,
    new QName( _schema.targetNamespace.uri, "groups") );

Super simple.

D’un XML vers un Object

C’est magique, c’est tout pareil ! au lieu d’utiliser XMLEncoder, on utilise XMLDecoder, et on change la référence de l’objet par notre XML :

var obj : ArrayCollection = _xmlDecoder.decode( myXml,
    new QName( _schema.targetNamespace.uri, "groups") ) as ArrayCollection;

Automatisation

Je vous propose un set de classes pour faire tout ça de manière automatique.

• XSDConverter : un convertisseur XML via XSD.
  2 méthodes :
  • importFromXml( xml : *, xsdUrl : String, schemaTypes : Vector. = null ) : void
  • exportToXml( target : Object, xsdUrl : String, schemaTypes : Vector. = null ) : void

  En paramètre de ces méthodes :

  • la source : Object pour l’exportation, une String, un XML ou un XMLList pour l’importation;
  • xsdUrl : l’url de la xsd a charger;
  • schemaType : une collection (Vector) d’objet de type XSDType, définissant le mapping entre les types XSD, et les classes référentes AS.
• XSDEvent : l’évènement diffusé par XSDConverter (importSuccess, exportSuccess et conversionError (en cas de problème de conversion ou de chargement de la XSD ) ).
• XSDType : définition d’un type XSD, avec la classe AS associée.

Un petit exemple est disponible là, avec les sources sous ce lien.

Et donc….

… vous pouvez vous dire que “Ahh ! Maintenant que mes données sont automatiquement transformées en XML, je me sens mieux. Et comme j’ai gagné plein de temps, ba du coup je peux lire des articles fort intéressants comme ceux concernant le skinning ou les primitives dans Flex4. De toutes façons y’a trop de monde à la Fnac pour finir mes cadeaux….”

Autres articles sur le même sujet

• Pti truc du jour : Les CollectionEvent
• Cairngorm pour les fainéants… Tour d’horizons des code generator
• Developing with AFCS a.k.a Cocomo – Introduction
• Reflex #2 : vous reprendrez bien un peu de IOC ?

Vous venez de créer votre douzième workspace Eclipse/Flex Builder ??? Et vous en avez marre de recréer vos perspectives, et autres vues… à chaque fois ???

Mais pourquoi diable n’utilisez vous pas les « fameux » ‘working sets’ ?

Et puisque quelques pixels valent pleins de mots…

Les working sets ( prononcez ‘setss’ )… tout simplement la solution moderne aux problèmes de congestion de projets dans Eclipse & Flex Builder !Autres articles sur le même sujet

• WTP – Flex Buider : résoudre les problèmes de mémoire
• L’erreur est humaine… debuguer un projet Flex distant via Flex Builder
• Flex Builder 3 et le PHP ( PDT ) : installation
• Flex et les warnings inutiles…

Dans ce 1er exemple d’application Cocomo Adobe Flash Collaboration Services aka A.F.C.S, nous allons développer, à vrai dire « assembler », une application de visioconférence intégrant un tchat, des notes partagées et un gestionnaire de partage de fichiers. Pour cela nous allons utiliser des pods, les composants de plus haut-niveau fournis dans cocomo AFCS .

L’un des principaux composants d’une application cocomo AFCS est le gestionnaire de session. C’est lui qui sera chargé de la communication avec les serveurs cocomo AFCS , et donc de l’identification des utilisateurs, de la gestion de leur connexion, de la synchronisation des données… et plus encore…

Deux composants peuvent jouer ce rôle : ConnectSessionContainer et ConnectSession ( tous deux implémentent com.adobe.rtc.session.IConnectSession ).

Hello AFCS ( bye Cocomo )

Pour commencer :

- créer un nouveau projet Flex,
- copier le SWC Cocomo AFCS (depuis CocomoSDK_0.9/lib/player 9 ou 10/afcs.swc) et collez-le dans votre répertoire /libs/

Il s’agit d’un composant basé sur la classe Canvas, et intégrant toute la « mécanique » nécessaire à la communication avec les serveurs cocomo AFCS .

Il est à noter que le ConnectSessionContainer, et donc ses « composants-enfants », resteront invisibles tant que la communication avec salon ne sera pas établie. C’est pour cette raison que nous allons lui intégrer nos pods ( WebCamera, SimpleChat, Notes et FileShare ).Tant que la connexion ne sera pas établie, aucun des composants ne sera visible.

Pour débuter une session, nous devrons renseigner deux propriétés du container de session :

• l’adresse du salon: roomURL ( exemple : http://connectnow.acrobat.com/votreCompte/nomSalon )
• les identifiants de connexion : authenticator

La transmission des identifiants se fait par l’intermédiaire de la classe AdobeHSAuthenticator.Elle a pour fonction d’encapsuler les informations relatives à l’identification( userName, password ). Plusieurs modes d’authentification sont possibles, nous nous y interresserons plus tard.

Dans un premier temps nous nous contenterons d’inscrire nos identifiants « en dur » dans notre application.

On peut noter que les composants liés à AFCS se référent au namespace ‘AfcsNameSpace’ ( anciennement ‘CocomoNameSpace’ dans version 0.9 )

<?xml version="1.0" encoding="utf-8" ?>
<mx:Application layout="absolute"
 xmlns:mx="http://www.adobe.com/2006/mxml"
 xmlns:rtc="AfcsNameSpace"
 >
<rtc:ConnectSessionContainer id="sessionManager" width="500" height="400"
 roomURL="http://connectnow.acrobat.com/yourAccount/roomName"
 authenticator="{identificator}"
 backgroundColor="#FFFFFF"
/>
<rtc:AdobeHSAuthenticator id="identificator"
 userName="votreLogin" password="VotreMotDePasse"
/>
</mx:Application>

À ce stade, l’application peut déjà se connecter. Par défaut, dès que le connectSessionContainer est créé, il tente d’initier la communication avec les serveurs. Dans cet exemple, j’ai ajouté une couleur de fond pour le container, de manière à pouvoir observer lorsque la connexion au salon est réussie.

Si vous publiez le projet en mode debug vous verrez les logs relatifs aux communications client/serveur.

Pour vérifier si l’authentification est correcte, nous pouvons déclarer des écouteurs d’événements AuthenticationEvent.AUTHENTICATION_FAILURE et AuthenticationEvent.AUTHENTICATION_SUCCESS sur AdobeHSAuthenticator.

Pour capter le moment où notre application est connectée et synchronisée, nous pouvons ajouter un écouteur d’événement SessionEvent.SYNCHRONIZATION_CHANGE sur le container, et surveiller sa propriété ‘isSynchronized‘. Nous reviendrons prochainement sur les différents aspects et acteurs en jeu lors de cette synchronisation.

<?xml version="1.0" encoding="utf-8" ?>
<mx:Application layout="absolute"
    xmlns:mx="http://www.adobe.com/2006/mxml"
    xmlns:rtc="AfcsNameSpace"
>
     <mx:Script>
         <![CDATA[
             import mx.controls.Alert;
             import com.adobe.rtc.events.SessionEvent;

             // session's state
             private var isConnected:Boolean = false;

			// when a "server synchronization" event is dispatched
             public function onSynchro( e:SessionEvent ):void
             {
                 if ( sessionManager.isSynchronized &&  ! isConnected )
                 {
                     Alert.show("Application connectée");
                     isConnected = true ;
                 }
             }
     ]]>
 </mx:Script>
<rtc:ConnectSessionContainer id="sessionManager"
    width="100%" height="100%" backgroundColor="#FFFFFF"
    authenticator="{identificator}"
    roomURL="http://connectnow.acrobat.com/regartdemo/meetingzone"
    synchronizationChange="onSynchro( event )"
/>
<!-- Authentication component -->
 <rtc:AdobeHSAuthenticator id="identificator"
   userName="YourUserName" password="YourPassword"
   authenticationSuccess="Alert.show('authentication success')"
   authenticationFailure="Alert.show('authentication failed')"/>
</mx:Application>

Maintenant que notre connexion parvient à se connecter au salon, nous allons pouvoir intégrer les pods.

Utilisation des pods

Les pods sont des composants collaboratifs « prêt à l’emploi« . Lorsque vous utilisez un ConnectSessionContainer, il suffit d’insérer vos pods à l’intérieur pour qu’ils puissent repérer la connexion établie et l’utiliser.

À ce jour, les pods disponibles sont :

• SimpleChat : composant de « clavardage » permettant l’envoi de messages publics et privés
• WebCamera : composant de visioconférences
• FileShare : composant de partage de fichier ( upload / download )
• Note : composant de partage de notes
• Roster et HorizontalRoster : composant de gestion d’utilisateurs
• SharedWhiteBoard : tableau blanc partagé

Nous allons maintenant insérer les pods souhaités :

<rtc:ConnectSessionContainer id="sessionManager" width="100%" height="100%" backgroundColor="#FFFFFF"
   authenticator="{identificator}"
   roomURL="http://connectnow.acrobat.com/votreCompte/nomSalon"
   synchronizationChange="onSynchro( event )"
   >

   <!-- PODS -->
   <mx:VBox width="50%" height="100%" horizontalAlign="center">

      <rtc:WebCamera id="webcam" width="300" />

      <rtc:SimpleChat id="chat" width="100%" height="100%" />

   </mx:VBox>

   <mx:VBox width="50%" height="100%"  right="0">

     <rtc:FileShare id="fileManager" width="100%" height="50%" />

      <rtc:Note id="notes" width="100%" height="50%" />
   </mx:VBox>
</rtc:ConnectSessionContainer>

Les pods intégrent des mécanismes de gestion de droits. Nous y reviendrons …

Toujours est-il que voilà, vous avez créé votre première application cocomo AFCS , ou devrais je dire votre première application de « communication en temps réelle ». Mais comment faisait-on avant ???…

Identification et gestion de la connexion aux serveurs

Bon il manque encore quelque chose peut être… Pour un seul utilisateur çà irait presque… mais c’est pas le but :s…Comment fera-t-on si un jour on trouve des amis et qu’on veut collaborer avec eux ??? Tout le monde va se connecter avec le compte « d’admin » ??? Et n’importe quel décompileur AS3 va pouvoir récupérer les identifiants ? Pas très sécure… Heureusement cocomo AFCS nous permet de gérer facilement tous ces aspects.

Les serveurs cocomo AFCS permettent plusieurs types d’identification, notamment une connexion en tant que hôte, basée sur le compte cocomo AFCS Developper, et une connexion en tant qu’invité, ne nécessitant qu’un nom de participant.

Nous allons donc supprimer les attributs userName et password de l’AdobeHSAuthenticator, et ajouter un formulaire d’authentification à notre application. Ce formulaire permettra de choisir le type d’identification ( hôte ou invité ) :

<mx:Panel id="logPanel" >
   <mx:Form>

      <mx:FormItem label="Login">
         <mx:TextInput id="chp_login" />
      </mx:FormItem>

      <mx:FormItem label="your role :" direction="horizontal" >

         <mx:RadioButtonGroup id="userRole" />

         <mx:RadioButton id="isGuest" groupName="userRole"
            label="Guest" value="{UserRoles.VIEWER}"  selected="true"
         />
         <mx:RadioButton id="isOwner" groupName="userRole"
            label="Host" value="{UserRoles.OWNER}"
         />
      </mx:FormItem>

      <mx:FormItem label="Password"  enabled="{ userRole.selectedValue == UserRoles.OWNER }">
         <mx:TextInput id="field_password" displayAsPassword="true"  />
      </mx:FormItem>

      <mx:FormItem >
         <mx:Button label="Enter"
            click="login(chp_login.text , userRole.selectedValue == UserRoles.OWNER ? field_password.text : null  )"
          />
      </mx:FormItem>

   </mx:Form>
</mx:Panel>

La définition des rôles des utilisateurs est basée sur des valeurs numériques, définies dans des constantes de la classe UserRoles.

Les principaux rôles sont Owner ( hôte / propriétaire du salon ), Publisher ( participant autorisé à publier sur un ou plusieurs pods ) et Viewer ( invité seulement autorisé à utiliser le tchat ). Normallement, les invités ne peuvent utiliser un salon que si l’hôte est présent. Il est possible de modifier la configuration initiale des salons ( droit de publication automatique, persistence des données, entrée libre… ), ainsi que les rôles et les droits des utilisateurs connectés, pour cela nous pourrons utiliser l’application CocomoDevConsole AFCSDevConsole ou l’API directement. Mais c’est déjà une autre histoire…

Pour le moment, nous allons permettre à l’utilisateur de s’identifier à l’aide du formulaire. Pour cela nous devons désactiver la connexion automatique du gestionnaire de session en déclarant sa propriété autoLogin= »false ».

Pour finir, nous allons ajouter une méthode login() qui sera chargée de renseigner le AdobeHSAuthenticator, et de lancer la connexion du gestionnaire de session :

private function login ( login:String, password:String ):void
{
   identificator.userName = login;
	//if password is set : log as host
	//else log as guest
   identificator.password = password ;

	// run sessionManager connection
   sessionManager.login();
}

Nous allons ensuite rajouter un bouton et une fonction de déconnexion.

// disconnection
// in actual 0.9 beta, mostly pods, can't be re-connected after a disconnection

private function logout():void
{
    sessionManager.logout();

	// close() is supposed to disconnect et remove all childNodes, but seems not work yet
    //sessionManager.close();
}

<mx:VBox width="50%" height="100%" horizontalAlign="center" right="0">
    <mx:Button label="Logout" click="logout()" />

    <rtc:FileShare id="fileManager" width="100%" height="50%" />

    <rtc:Note id="notes" width="100%" height="50%" />
</mx:VBox>

Dès que l’application sera connectée, nous supprimerons le formulaire, et en cas de déconnexion le gestionnaire de session sera supprimé :

// for each synchronization event
// : connection, disconnection , state's change, ...
private function onSynchro( e:SessionEvent ):void
{

	// once application is successfully connected / synchronized
    if ( sessionManager.isSynchronized && ! isConnected )
    {
        Alert.show("Application connectée");

        isConnected = true ;

        removeChild( logPanel );

    } else if ( ! sessionManager.isSynchronized && isConnected ){
    // if disconnected
    isConnected = false ;

   /* remove the connectSessionContainer
   *  » in this version disconnected pods can't re-connect
   *
   *  » For re-connect, you can :
   *     - reload html page
   *     - dynamically re-create connectSession and pods
   */
   removeChild( sessionManager );

   // display logout message
   Alert.show( 'vous avez quitté la réunion, recharger la page pour entrer à nouveau');
   }
}

La gestion des déconnexions / reconnexions semblent pour le moment un peu instables. Mais bon on est prévenu, c’est une béta. Après quelques tests, je crois que le meilleur moyen de revenir dans un salon après s’être déconnecté, est de recharger la page.

Accéder aux sources complétes

Voilà la fin de ce premier exemple d’utilisation de cocomo AFCS , et il est bien entendu possible d’aller beaucoup plus loin. La prochaine fois nous nous intéresserons de plus près aux différents mécanismes articulés au sein de cocomo AFCS , et plus globalement à l’architecture du service. Nous utiliserons également la CocomoDevConsoleAFCSDevConsole et le LocalConnectionServer, les deux outils AIR proposés dans le SDK.

D’ici là bonne collaboration !!!

Autres articles sur le même sujet

• Cocomo est là et personne me prévient ??!!
• Cocomo ? Kezako ?
• Utiliser le DragManager de Flex ( 1ère partie )
• Developing with AFCS a.k.a Cocomo – Introduction

Hey there!
Here is, as a first English article, an introduction to Adobe Cocomo AFCS.
(Translated from French tutorial on FlashXPress )

Cocomo is an abbreviation of «COmmon COllaboration MOdel», which was the first name given by Adobe to its new online service dedicated to collaborative application development. The final commercial name is Adobe Flash Collaboration Services a.k.a AFCS

This name both references :

• a SDK that includes a Flex components library and tools dedicated to multi-users applications development. Just so you know, those components are used by Adobe for developing ConnectNow, a video conference application part of the Acrobat.com platform.
• a free online service (with some limitations), enabling creation and deployment of collaborative applications on FMS servers hosted and maintained by Adobe.

In short, Cocomo AFCS will allow us to develop applications that will use real-time communications capabilities of FMS servers, without taking care of those servers… cooool !!!

But what are the «real-time communications capabilities of those FMS servers» ???

In fact, the Cocomo AFCS servers will allow us to:

• exchange audio and video data flows, useful to create visioconference application for example,
• synchronize different types of data between multiple client applications. It allows you to add a chat to an existing application, to develop a co-navigation system, a document co-edition functionnality, some multi-users game…
• share files
• manage user rights regarding their role

This schema describes the interaction between a room, hosted on a developer account of a cocomo server, and some Flex clients : the host user (owner), an active guest (publisher), and a passive guest. The host send his webcam output, and both host and publisher can update notes on the server, these data are broadcasted to the other clients.

The library contains «high-level» graphical components, known as pods, but also some more «low-level» classes that a developer can use to create his own components (SharedModel, CollectionNode).

This schema shows an example of pods (Tchat, Notes, User management, Webcam and File sharing)

The pods are collaborative «plug’n’play» components, that we will use to create our first Cocomo AFCS applications without having to write a single line of code (Tchat, Webcam, Notes…). The lower level classes will help us to go deeper and create components that will fit more specific needs.

But, first things first : let’s create a «Cocomo AFCS Developer» account…

Cocomo AFCS Developer account creation

To create an account :

• Go to the Cocomo AFCS portal (https://cocomo.acrobat.com),
• Create a new account (you can also use your existing Adobe account)
• Choose a Cocomo AFCS account identifier («account name», room access URLs will be based on that identifier)
  1. The Account URL situation in the screen
  2. The Room instances panel (click the « Add » button)
  3. The « Download SDK » button


This capture represents the Cocomo AFCS home page. It mainly illustrates the three steps to follow:

• Once your account has been created, make sure to note your Account URL
• In the « Room instances » panel, create a new room. A room represents a « virtual meeting point » where several client application will be able to exchange audio / video flows, files or messages. Your account will allow you to create several rooms, with a single configuration for each room. A room is also identified by a URL that looks like http://connectnow.acrobat.com/yourAccount/roomName.
• Once your room has been created, download the SDK.

You’ll find within the downloaded ZIP:

• documentation
• application examples
• Air utilities: CocomoDevConsole AFCSDevConsole for your accounts and rooms management, and LocalConnectionServer, a local Cocomo AFCS server emulation that will allow you to test some of your applications features without having to connect to a « real » Cocomo AFCS server (mainly messaging)
• library sources
• library SWC for Flash Player 9 and Flash Player 10

Cocomo AFCS installation

For this version (0.9), installation will reside in including Cocomo AFCS library documentation at Eclipse’s one. To do so:

• create a ‘com.adobe.afcs‘ folder in the ‘plugins‘ folder of your Flex Builder installation
  Windows: C:\Program Files\Adobe\Flex Builder 3\plugins\com.adobe.afcs
  Macintosh: /Applications/Adobe Flex Builder 3/plugins/com.adobe.afcs
• Copy the content of the downloaded file into that folder
• (Re)Launch Flex Builder and open the help contents (Help / Help Contents)

You should now find the Cocomo AFCS API documentation

This schema is a screen capture of the cocomo documentation opened within the Flex Builder environment.

And noooow… let’s collaborate !!!
>> Next : My first Cocomo AFCS ApplicationAutres articles sur le même sujet

• Cocomo est là et personne me prévient ??!!
• Cocomo ? Kezako ?
• Introducing r.CØ … First « Cocomo ready » Air Wiibot…
• Hello AFCS ( bye Cocomo ) : première application multi-utilisateurs

Je vous suggère vivement si vous n’avez pas lu l’article ou si vous ne connaissez pas encore grand chose au développement sous iPhone de vous y intéresser pour mieux aborder cette suite…

Une dernière chose avant de démarrer : massez-vous les tempes, faites-vous un petit café…
Prêt ?

Installer le SDK iPhone

A l’heure ou j’écris ces lignes, Apple en est à la version 2.2 du SDK iPhone.
L’installation vous mettra à disposition tous les outils dont je vais parler ici.

Ouvrir un projet d’exemple pour se familiariser avec la structure d’un projet iPhone

Je considère à présent que vous avez déjà un Mac (bah oui…), et le SDK iPhone installé dessus.

1. Ouvrez XCode.
   
2. Faites Fichier > Nouveau projet…
   
3. Choisissez « View-Based Application »
4. Entrez le nom de projet « LaFabrick » puis choisissez un emplacement, vous arrivez alors sur l’interface principale d’Xcode.

Voyons maintenant les fichiers que nous avons :

Nous sommes en Objective-C, donc pour chaque classe, vous trouverez un fichier .h définissant l’interface et un fichier .m contenant l’implémentation (amis du C bonjour !).
Ouvrons « LaFabrickAppDelegate.h »

On constate dans cette interface les déclarations d’un objet fenêtre (objet de base utilisé pour l’affichage) et le contrôleur LaFabrickViewController que nous étudierons rapidement après.
L’implémentation est simple :

Lorsque l’application vient d’être démarrée applicationDidFinishLaunching, on demande l’affichage de la vue contrôlée par notre LaFabrickViewController dans la fenêtre [window addSubview:viewController.view];.
Notez enfin la notation à crochet pour appeler une méthode d’un objet : oui oui, c’est relou.

Jetons maintenant un oeil à LaFabrickViewController (.h et .m) : il est quasiment vide ! C’est effectivement là qu’on doit travailler un peu…
Quelques questions se posent :

• Où est la vue ?
• Comment est-elle associée au contrôleur ?

Nous allons voir cela avec l’interface builder.

Utilisation de l’Interface Builder pour gérer la vue

Première réponse : notre vue est ici créée à partir d’un fichier de description d’interface géré par l’interface builder : LaFabrickViewController.xib. Double-cliquez dessus, l’interface suivante s’affiche alors :

On constate notamment dans la fenêtre centrale, les éléments suivants :

• File’s owner : LaFabrickViewController
• View : UIView

OK, donc le .xib permet de dire que la vue est associée au contrôleur LaFabrickViewController, voilà la deuxième réponse !

Sélectionnez à présent la ligne View : UIView puis sélectionnez le second onglet dans la fenêtre de droite.
Note : si cette fenêtre n’est pas visible, faites Tools > Identity Inspector

Vous pouvez visualiser l’association entre la vue View et la propriété view du contrôleur LaFabrickViewController.

Cette partie est primordiale pour que l’affichage de la vue soit effectif : souvenez-vous que dans LaFabrickAppDelegate, on charge la propriété « view » de LaFabrickViewController, aussi sans l’association effectuée dans l’Interface Builder, il serait impossible d’afficher quoi que ce soit !

D’une manière générale, chaque élément ajouté depuis l’Interface Builder devra être lié à une propriété du contrôleur (ou d’un délégué) via l’Interface Builder afin que vous puissez interagir avec depuis le code.
La propriété en question est alors nommée « Outlet » côté Interface Builder, soit « Sortie » si l’on traduit litéralement : c’est effectivement un paramètre de sortie de votre interface.

Personnaliser un peu l’interface

Depuis l’Interface Builder, ajoutez deux champs texte, deux labels et un bouton histoire d’obtenir à peu près ça :

Si vous faites Tools > Reveal in Document Window… vous verrez l’arborescence de contrôles de la vue mise à jour.

Il est maintenant temps de contrôler ces éléments depuis notre LaFabrickViewController.
Pour cela deux méthodes :

1. Directement depuis Interface Builder (cf. vidéo de démonstration)
   • Sélectionnez LaFabrickViewController depuis le Document Window
   • Dans « l’Inspector » (fenêtre de droite) choisissez le dernier onglet (i) puis ajoutez les propriétés via la section « Class Outlets »
     
   • Ceci fait vous devez enregistrer les modifications dans le fichier LaFabrickViewController.m. Pour cela, vous devez utiliser la fonction File > Write class files…
   • Faites alors « Save »
   • L’outil vous demande si vous souhaitez fusionner ou écraser : choisissez Merge (fusionner)
   • Le fichier .m n’est pas modifié, vous pouvez le fermer, en revanche vous constaterez que le .h peut être modifié comme suit :
     
     sous réserve que vous choisissiez l’action « Choose left » depuis le menu déroulant du bas
   • Sauvegardez (enfin) votre fichier fusionné
2. Mix XCode et Interface Builder
   • Déclarez manuellement les propriétés correspondant aux contrôles que vous souhaitez manipuler dans l’interface (LaFabrickViewController.h) :
IBOutlet UITextField *lastNameField;
IBOutlet UITextField *nameField;
IBOutlet UIButton *validateButton;

   • Compilez le projet
   • Rouvrez l’Interface Builder pour faire les liens

Note : la première méthode a le mauvais goût d’ouvrir l’outil de fusion de fichiers pour que vous validiez que rien n’est écrasé ou ajouté sans votre accord.
J’avoue que, malgré la nécessité de la fusion, je trouve ça très peu pratique voire franchement lourdingue, je m’attendais à mieux venant d’un monstre de l’ergonomie. Mais c’est le prix à payer pour avoir deux outils quasiment indépendants, et enfin, si vous connaissez une meilleure méthode, n’hésitez pas à poster !

– ca se voit tant que ça que je préfère la méthode à l’ancienne ? –

Ce n’est pas encore tout à fait terminé ! (si si je vous jure, c’est long)
Il reste à faire les fameux liens entre les contrôles de la vue et les propriétés que nous avons créé dans LaFabrickViewController. Pour cela, rien ne vaut l’image (et en plein écran tant qu’à faire) :

Voilà ! Vous avez lié les contrôles de votre vue à des propriétés de votre contrôleur.
Nous utiliserons désormais la technique décrite ci-dessus pour gérer nos association vue-contrôleur.

Reprenons Interface Builder pour créer un handler gérant le clic sur le bouton. Pour cela :

1. Sélectionnez LaFabrickViewController depuis la Document Window
2. Dans le dernier onglet de l’Inspector, cliquez sur le bouton + de la section Class Actions en entrez buttonClick:. Laissez le Type sur id
3. Sauvegardez, faites Write class files…, fusionnez les sources et enregistrez
4. Faites un lien entre l’événement Touch up Inside de votre bouton et LaFabrickViewController, l’éditeur vous propose alors votre fonction buttonClick:

Maintenant que votre événement est lié à votre contrôleur, ajoutons un bout de code bateau juste pour valider que l’ensemble fonctionne bien :

1. Retournez sous XCode, et ouvrez LaFabrickViewController.m
2. Modifiez le code pour avoir la méthode buttonClick: sous la forme suivante :
   - (IBAction)buttonClick:(id)sender {
[firstNameField setText:[lastNameField text]];
} 

   Le principe étant simplement de modifier le texte du prénom avec le texte du nom (je vous avais prévenu, c’est un bout de code bateau)

3. Faites Build and Go et testez !

Bien, il ne reste plus qu’à apprendre Objective-C. Pour cela, rien ne vaut quelques ressources dédiée au sujet :

• Passage de C++ à Objective-C
• Passage de Java à Objective-C

Voilà, vous avez à présent les bases nécessaires pour démarrer le développement d’une application iPhone.
A bientôt !Autres articles sur le même sujet

• L’erreur est humaine… debuguer un projet Flex distant via Flex Builder
• [Flex 3 Beta] bug : Application File doesn’t exist
• Développer une application iPhone – Introduction aux concepts de base
• Reflex #1: une micro-architecture pour Flex… simple !

Il est des petits appareils qui font envie de nos jours : l’iPhone fait certainement partie des premiers de cette liste.

Voilà donc un tutoriel d’approche d’une technologie nouvelle pour des personnes n’ayant aucune notion de développement dans ce domaine.

Je parlerai donc ici :

• Des principaux concepts à maîtriser absolument pour bien démarrer un développement pour iPhone
• De quelques exemples permettant d’illustrer les concepts

Je ne parlerai pas :

• Des différences entre un développement pour Mac par rapport à un développement pour iPhone
• De quelconques « best practices » de développement

Il s’agit plutôt d’un retour d’expérience qui permettra peut-être à d’autres personnes d’appréhender un développement pour iPhone sans trop se casser les dents.

Pour la suite, la documentation fournie par Apple est très complète et peut vous donner de quoi satisfaire vos nuits blanches pour un bon moment !

Pour bien démarrer

1. Comprendre l’environnement nécessaire au développement d’une application iPhone
   1. Les principaux concepts
   2. Les outils
2. Ouvrir quelques projets d’exemple pour se familiariser avec la syntaxe Objective-C
3. Créer son premier projet

Ce premier article présente les concepts et introduit la liste des outils nécessaires au développement.

Note aux pressés (j’en fais généralement partie)

Si vous grillez les deux premières étapes, vous risquez rapidement de vous rendre compte qu’elles vous manquent et perdrez certainement beaucoup plus de temps que si vous y consacrez une petite journée.

Comprendre l’environnement nécessaire au développement d’une application iPhone

Les principaux concepts

Pour commencer, il est indispensable de maîtriser quelques bases de fonctionnement d’un programme iPhone.

Une application iPhone est une application MVC dans sa plus pure forme. Vous concevez des vues, manipulées par des contrôleurs en faisant transiter des données d’un modèle.

Application delegate

Il s’agit de la classe en charge du lancement de l’application et de l’affichage de la fenêtre principale.
Vous pouvez vous en servir pour initialiser des éléments particuliers communs à l’ensemble des éléments de votre application :

• connexion à une base de données,
• configuration générale,
• …

View controller

Classe gérant la vue et pouvant recevoir les événements propres aux composants de la vue gérée.

View

Une vue, chargée d’afficher des contrôles.

Il faut savoir qu’une vue peut être créée par programme ou en utilisant des fichiers de ressources définis à l’aide de l’interface builder.

Ce sont deux moyens différents qui présentent leurs avantages et inconvénients… A vous de voir lequel convient le mieux à telle ou telle situation.

Delegate

C’est un terme souvent employé dans un programme.

Un délégué est un objet prenant en charge un certain nombre de méthodes remplissant des fonctions propres à un émetteur.

En pratique, un view controller est, dans la plupart des cas, désigné comme délégué des composants de la vue et va implémenter les méthodes répondant aux événements que chacun d’entre eux déclenche.

Par exemple, un composant table view (tableau) va appeler différentes méthodes de son délégué pour pouvoir s’afficher convenablement :

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
Doit renvoyer le nombre de sections dans le tableau

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
Doit renvoyer le nombre de lignes du tableau à afficher pour la section dont le numéro est passé en paramètre

- (UITableViewCell *)tableView:(UITableView *)tv cellForRowAtIndexPath:(NSIndexPath *)indexPath
Doit initialiser une cellule du tableau pour le numéro de section et de ligne passé en paramètre

Ce mode de fonctionnement permet notamment que n’importe que objet soit désigné comme délégué. On peut donc très bien imaginer avoir les deux possibilités suivantes :

• Le schéma A montre l’exemple le plus courant : une seule classe faisant office de ViewController et de Delegate pour l’ensemble des contrôles de la vue.
• Le schéma B montre une alternative intéressante lors de gestion de vues complexes : une classe Delegate par contrôle et un ViewController standard.

La différence entre ces deux solutions, c’est que le premier ViewController contiendra l’ensemble du code de BoutonDelegate, Tableau1Delegate et Tableau2Delegate, le rendant peut-être plus complexe à lire et à comprendre.

Ceci étant dit passons aux outils.

Les outils

Vous avez trois outils à votre disposition :

1. XCode : l’environnement de développement en charge de coder, compiler et lancer la deuxième application
2. Le simulateur iPhone : une application simulant à quelques restrictions près un iPhone et vous permettant de tester unitairement vos fonctionnalités
3. Interface Builder : l’outil de création d’interfaces (écrans, vues…)

XCode est un peu l’application maître et lance ses 2 gentils larbins pour faciliter le développement.

Dans le prochain article, passage aux choses sérieuses : nous ouvrirons XCode pour voir comment cette théorie se traduit en pratique, histoire d’illustrer un peu ces jolis concepts.

A la prochaine !
Autres articles sur le même sujet

• Petit cours sur l’API de dessin
• Cairngorm pour les fainéants… Tour d’horizons des code generator
• Développer une application iPhone – XCode et Interface Builder passés au crible
• Hello AFCS ( bye Cocomo ) : première application multi-utilisateurs

Ce type d’évenement, géré par toutes les classes implémentant ICollectionView, est généré lors d’un changement de la collection . Il en devient du coup un complément très intéressant au Databinding.

Imaginons par exemple une application de gestion de notes :

Exemple / Source

L’affichage des notes dans le Datagrid est assuré grâce à un databinding avec une arrayCollection.

<mx:DataGrid id="notesDGrid" dataProvider="{notesCollection}" />

Lorsqu’on ajoute un élément, la collection change, l’affichage est automatiquement mis à jour.

Par contre, pour la note moyenne, calculée à l’ouverture à partir des élements présents, le binding ne permettra pas la mise à jour automatique.

C’est là qu’interviennent les CollectionEvent : en ajoutant un écouteur sur la collection, on peut réagir à ses modifications :

notesCollection.addEventListener(
     CollectionEvent.COLLECTION_CHANGE ,
     updateMoyenne
);

Dans notre exemple, l’application va recalculer la moyenne lors de chaque ajout.

Plus fort encore, les CollectionEvent possédent une propriété ‘kind’, qui permet de savoir quel type d’opération a été effectué ( Ajout, deplacement, supression ) et une ‘items’ de récupérer des informations sur la dîte opération ( item ajouté, nouvelle position .. ) .

L’exemple est très simpliste, mais dans le cas d’un dév avec Cairngorm par exemple, je vous laisse imaginer l’intérêt de cette fonctionnalité utilisée sur les collections d’un modelLocator

Toutes les infos sur LiveDocsAutres articles sur le même sujet

• Utiliser le DragManager de Flex ( 1ère partie )
• Object to XML to Object : conversion XSD
• Développer une application iPhone – XCode et Interface Builder passés au crible
• Hello AFCS ( bye Cocomo ) : première application multi-utilisateurs

1. les warnings liés à des feuilles de styles définissant des propriétés de styles pour des composants inexistants dans l’application au moment de la compilation

» la solution

Ajouter cette ligne au compilateur :

 -show-unused-type-selector-warnings=false

Voilà une bonne occasion de (re)jeter un petit coup d’oeil aux différentes options de compilation.

via Daniel R.

2. les warnings de validation HTML lorsque l’on installe PDT ( PHP Development Tools )

» la solution rapide ( mais pas valide )

• Ouvrir les préférences de Flex Builder ( ou d’eclipse )

• Dans le panneau ‘Validation’ , décocher les lignes correspondants au HTML

• lancez un clean de votre projet

Eh ben voilà c’est plus propre, je me sens mieux

PS : y a aussi une solution encore plus propre pour les warning HTML… c’est de créer un template valide grâce à SwfObject. J’y reviendrais…
UPDATE : Toutes les infos nécessaires sur le wiki Mediabox Adaptez le template HTML de flex builder à l’utilisation de SWFObjectAutres articles sur le même sujet

• Installer son environnement de développement : Tomcat – Eclipse – WTP – Flex Builder
• L’erreur est humaine… debuguer un projet Flex distant via Flex Builder
• Flex Builder 3 et le PHP ( PDT ) : installation
• Vous reprendrez bien un set de travail !?

En fait, quand on utilise cairngorm dans un projet avec plusieurs commandes, et quelques écrans, ça devient vite le Bowdel, pour une commande, 2 voir 3 de fichiers à écrire, souvent les mêmes mais qui changent un peu, à 3 mots prêts… Donc au final, on gagne du temps parce qu’on utilise cairngorm et qu’on ré-invente pas la roue mais on en perds parce que c’est pas super pratique à utiliser… Je dirai que c’est le même combat pour des projets de Remoting, avec coté serveur, le développement des méthodes Création / Ajout / Suppression / Modification (CRUD) pour les objets (VO,DTO au choix) que l’on utilise dans notre appli…

C’est la que les outils de générations automatiques du codes interviennent, plus ou moins bien fichus, plus ou moins bien intrégrés.

Pour Cairngorm

cairngen

Sous la forme d’une tache ANT, on peut, à partir d’un fichier properties, créer l’arborescence type de cairngorm, créer le ModelLocator, le Controller, le service Locator, des VO, et les sequences Event / commandes / Delegate, la totale quoi. Comme c’est une tache Ant, c’est parfaitement intégré à FlexBuilder / Eclipse. Ca prend 5min à configurer et ça fait gagner pas mal de temps. Pour ceux qui voudraient en apprendre un peu plus sur Ant, je vous invite à explorer les sources, ça fournis un bon exemple pratique.

CairngormCreator

C’est un outil de génération en ligne, qui fournit une interface graphique. Il permet d’aller assez loin en terme de personnalisation, on peut en plus de toute la base (Arborescence Cairngorm, ModelLocator, Controller, ….) créer des vues, et même les squelettes de classes qui seront dans un package Utility. Il fournit aussi un fichier de build pour compiler l’appli… il est même possible de visualiser les sources générées. Quand on a fini, on peut télécharger une archive qui contient tous nos fichiers.

FCG – Flex Cairngorm code generator (par Dehats)

FCG est une appli Air. La différence avec les précédents outils, c’est qu’il est « intelligent ». Il peut lire les sources / java / php de nos objets coté serveurs et il crée aussi les fichiers AS / Mxml qui vont bien, en plus des classes de bases de cairngorm. On a un outil bien complet et assez bien fait que j’ai malheureusement pas eu le temps de le tester, par contre, sur le site, on peut voir une démo en vidéo… ça donne envie, ca à l’air d’être un bon outils pour préparer son projet Cairngorm. (A quand un outils, qui par de l’UML … )

Pour info, il existe aussi un générateur en ruby sur googleCode… mais je fais pas ruby !

Coté serveur

DAOGen

La, rien a voir avec cairngorm, puisqu’on a que la partie objets serveur (+ connections à une BDD). Ici le point de départ, c’est la base de données. On crée des tables un peu comme avec phpMyAdmin. On choisi son langage coté serveur (pour l’instant JAVA / PHP ) et au final, en plus des fichiers DAO dans le langage choisi, on a les fichiers SQL pour créer les tables… la classe !

Après, on a aussi des truc genre La Grosse Berta, qui font le flex, le partie serveur… pas encore le café… mais bon on leur fait confiance ça devrait pas tarder…

Simple CRUD code generator

Génération en ligne, le générateur se connecte à votre base et génère les classes php (5) des VO, les classes qui gèrent les transactions… le tout pour après faire du remoting avec amfphp1.9.

Et quelques mots pour conclure…

Le premier point, c’est que c’est des outils, pas autres choses, ils codent pas à notre place. Leur but est juste de supprimer des parties redondantes ou commune à la mise en place de projet Cairngorm, utilisant du Remoting ou pas…

De mon point de vue, le plus important dans ces outils, c’est leur rapidité d’utilisation, faut pas qu’on passe 3 heures à tout configurer aux petits oignons pour avoir une génération parfaite. Je pense qu’on gagne plus de temps à avoir une génération « presque parfaite » mais qui nécessite beaucoup moins de temps de préparation, et pour ca j’aime bien cairngen, car après l’avoir personnalisé, on modifie 10 lignes dans un fichier properties et c’est parti… par contre il fait que la partie flex. J’aime bien aussi l’approche de parti de la base de donnée pour généré ce qu’il faut coté serveur.

En tout cas après ça, si vous utilisez pas cairngorm… c’est que que vous avez une bonne raison !Autres articles sur le même sujet

• L’erreur est humaine… debuguer un projet Flex distant via Flex Builder
• Utiliser Cairngorm dans un projet Flex / AMFPHP
• Pti truc du jour : Les CollectionEvent
• Flex et les warnings inutiles…

((/blog/images/images.jpeg|foot on moon))

insertChild

on a du xml :

var x : XML =
<books>
  <book title="Harry potter et l'ordre de phoenix">
    <chapitre nom="HPOPchapitre 1" test="B"/>
    <chapitre nom="HPOPchapitre 2" test="B"/>
    <chapitre nom="HPOPchapitre 3" test="B"/>
  </book>
  <book title="Harry Potter et prince de sang mele">
    <chapitre nom="HPPSMchapitre 1" test="a"/>
    <chapitre nom="HPPSMchapitre 2" test="yoy"/>
    <chapitre nom="HPPSMchapitre 3" test="B"/>
  </book>
  <book title="Harry potter et les reliques de la Mort">
    <chapitre nom="HPRMchapitre 1" test="B"/>
    <chapitre nom="HPRMchapitre 2" test="B"/>
    <chapitre nom="HPRMchapitre 3" test="B"/>
  </book>
</books>

on voudrait ajouter un livre:

    var book : XML = <book title="StarWars" /> ;

on lit la doc (http://livedocs.adobe.com/labs/flex3/html/help.html?content=13_Working_with_XML_07.html) et on trouve un truc du genre

    x = x.insertChildAfter(x.book[0], book);

Et x donne ca :

<books>
    <book title="Harry Potter et l'ordre du phoenix">
    <chapitre nom="HPOPchapitre 1" test="B"/>
    <chapitre nom="HPOPchapitre 2" test="B"/>
    <chapitre nom="HPOPchapitre 3" test="B"/>
  </book>
  <book title="StarWars"/>
  <book title="Harry Potter et prince de sang mele">
    <chapitre nom="HPPSMchapitre 1" test="a"/>
    <chapitre nom="HPPSMchapitre 2" test="yoy"/>
    <chapitre nom="HPPSMchapitre 3" test="B"/>
  </book>
  <book title="Harry potter et les reliques de la Mort">
    <chapitre nom="HPRMchapitre 1" test="B"/>
    <chapitre nom="HPRMchapitre 2" test="B"/>
    <chapitre nom="HPRMchapitre 3" test="B"/>
  </book>
</books>

Cool ca marche

Et puis bon on se dit qu’on a bien compris, alors pourquoi pas rajouter un chapitre…
on tente :

     var chapitre : XML = <chapitre nom="HPRMchapitre2.5" /> ;
     x = x.insertChildAfter(x.book[0].chapitre[1], chapitre);

mais ça marche pas… pourtant on fait tout comme la documentation ???
En fait, pour insérer un noeud xml il faut surtout appeler insertChildAfter sur le noeud parent du noeud qui sera inséré…

    var after : XML = x.book[1].chapitre[1];
    var after_parent = after.parent();
    after_parent = after_parent.insertChildAfter(after,chapitre);

et la ca marche… plutôt bien

<books>
  <book title="Harry potter et l'ordre de phoenix">
    <chapitre nom="HPOPchapitre 1" test="B"/>
    <chapitre nom="HPOPchapitre 2" test="B"/>
    <chapitre nom="HPOPchapitre 3" test="B"/>
  </book>
  <book title="Harry Potter et prince de sang mele">
    <chapitre nom="HPPSMchapitre 1" test="a"/>
    <chapitre nom="HPPSMchapitre 2" test="yoy"/>
    <chapitre nom="HP 2.5"/>
    <chapitre nom="HPPSMchapitre 3" test="B"/>
  </book>
  <book title="Harry potter et les reliques de la Mort">
    <chapitre nom="HPRMchapitre 1" test="B"/>
    <chapitre nom="HPRMchapitre 2" test="B"/>
    <chapitre nom="HPRMchapitre 3" test="B"/>
  </book>
</books>

Les requetes

Sur des noeuds XML, on peut faire des requètes rapides à écrire,
Par exemple : Tout les chapitres , à n’importe quelle profondeur

    var chap : XMLList =  x..chapitre;

On peut compliquer en voulant le chapitre dont le paramètres test vaut yoy… ()

    var chap : XMLList = x..chapitre.(@test=="yoy");

Sauf que là, ça marche que si tout les noeuds chapitre ont cet attribut test, sinon ca génère un erreur…

Passer du XMLList au XML

Bon ca, c’est plus un pense bête, parce que ce matin, étant pas très réveillé, ca me paraissait super intéressant, beaucoup moins maintenant…
Concernant les requètes, elles sont super pratiques, facile à écrire !
On peux s’en servir pour retrouver un noeud précis dans le xml par exemple, pour utiliser ensuite insertChildAfter. Sauf que insertChildAfter, lui il prend du XML et pas du XMLList.
La solution, pour récupérer du XML, quand on utilise ce genre de requète, c’est d’utiliser les opérateurs [] pour accèder à l’objet XML contenu dans la XMLList.

    var chap : XML = x..chapitre.(@test=="yoy")[0];

Voilà j’avais prévenu, c’est pas la découverte du siècle Autres articles sur le même sujet

• Du HTML dans mon Flex…
• Flex et les warnings inutiles…
• Object to XML to Object : conversion XSD
• MdaME, ma résolution 2011 de génération de code AS3