Explication…

Layouts

Sans faire un article complet sur les layout (ce qui serait tout à fait possible et intéressant), on peut tout de même rappeler que le Flex 4 se distingue de Flex 3 via Spark par une volonté de mieux séparer le fond de la forme, il amène donc une notion de layout pour, comme son nom le suggère, organiser les composants d’un conteneur (par exemple un <s:Group>).
Exit donc la VBox ou la HBox (même si le VGroup ou le HGroup permettent de faire une transition en douceur), et bienvenue au Group avec layout :

<mx:VBox>
</mx:VBox>

devient donc

<s:Group>
<s:layout>
<s:VerticalLayout />
</s:layout>
</s:Group>

Au premier abord on dit : c’est plus verbeux ! Oui mais… le layout a cette particularité, en tant que propriété du composant, d’être modifiable à la volée, contrairement à un composant imposant sa mise en forme. Concrètement, là où la VBox présentera toujours ses enfants verticalement (c’est son nom !), le Group pourra changer à volonté de layout, donc très facilement passer de HorizontalLayout à VerticalLayout par exemple… On comprend encore mieux l’intérêt quand on se met à écrire son propre layout pour faire des choses un peu plus poussées visuellement !

Créer son layout

Pour créer un layout, il faut étendre la classe LayoutBase et surcharger a minima la méthode updateDisplayList() et certainement la méthode measure(). Ces méthodes gardent le même rôle qu’en Flex 3, mais avec l’adaptation contextuelle au Layout :

• updateDisplayList : dispose les enfants du conteneur et définit leur taille
• measure : donne la taille globale du conteneur

Vous pouvez accéder à la propriété « target » du layout qui correspond au conteneur auquel est appliqué le layout et travailler sur les enfant via les méthodes getElementAt() ou getVirtualElementAt(). La seconde méthode sert dans le cas où le layout est dit « virtualisé ».

Apparté : virtualisation de layout

Flex 4 permet, pour des raison de performance, d’utiliser un layout en mode « virtualisé », c’est-à-dire ne calculant la disposition des seuls enfants à afficher et non l’ensemble des enfants. Ce mode de fonctionnement s’applique particulièrement bien aux composants comprenant une liste de beaucoup d’enfants, mais ne calculant l’affichage d’une poignée à la fois, le reste attendant un scroll ou une action similaire pour être éventuellement affiché.

Application : création d’un ViewStackLayout

Avec les layouts en tête, il est inutile de demander pourquoi le composant ViewStack n’existe pas dans Spark : il devrait en pratique être un layout applicable à n’importe quel conteneur ! Même si le très bon article sur la virtualisation mentionne un prometteur je cite « (Planned) StackLayout », rien ne nous empêche d’en faire un simple, adapté à l’architecture Spark, plutôt que d’attendre (oui on est impatients à la fabrick).

Voici un exemple simple :

	import mx.core.IVisualElement;
	import spark.layouts.supportClasses.LayoutBase;

	public class ViewStackLayout extends LayoutBase {
		public function ViewStackLayout() {
			super();
		}

		protected var _index:uint;

		public function get index():Number {
			return _index;
		}

		public function set index(value:Number):void {
			if (_index != value && target != null && value >= 0 && value < target.numElements) {
				_index = value;
				target.invalidateSize();
				target.invalidateDisplayList();
			}
		}

		override public function updateDisplayList(width:Number, height:Number):void {
			var element:IVisualElement = useVirtualLayout ? target.getVirtualElementAt(index) : target.getElementAt(index);

			if (element) {
				element.setLayoutBoundsSize(element.getPreferredBoundsWidth(), element.getPreferredBoundsHeight());
				target.setActualSize(element.getPreferredBoundsWidth(), element.getPreferredBoundsHeight());
				target.setContentSize(element.getPreferredBoundsWidth(), element.getPreferredBoundsHeight());
			}
		}

		override public function measure():void {
			var count:int = target.numElements;

			for (var i:uint = 0; i < count; i++) {
				var element:IVisualElement = useVirtualLayout ? target.getVirtualElementAt(i) : target.getElementAt(i);

				if (i == index) {
					element.visible = true;
					element.includeInLayout = true;
					target.measuredWidth = element.getPreferredBoundsWidth();
					target.measuredHeight = element.getPreferredBoundsHeight();
				} else {
					element.visible = false;
					element.includeInLayout = false;
				}
			}
		}
	}

Vous noterez ici l’usage du getVirtualElementAt, en prévision de la gestion de la virtualisation.
Vous pouvez donc utiliser ce layout dans un DataGroup « piloté » par une tabbar par exemple comme ceci :

<s:TabBar id="tabEditors" />
<s:DataGroup id="editors">
<s:layout>
<mylayouts:ViewStackLayout index="{tabEditors.selectedIndex}" />
</s:layout>
<!-- Enfants... -->
</s:DataGroup>

De cette façon, le jour où vous voudrez présenter ces éléments sous forme de CoverFlow, en mode TimeMachine… vous n’aurez pas à modifier le code de votre composant, mais uniquement votre skin.

Alors, on n’est pas mieux habillé en Spark ?Autres articles sur le même sujet

• Reflex #1: une micro-architecture pour Flex… simple !
• Flex4 : composant personnalisé et skinning
• UIGFX practice : a CircularSlider component
• Proches de l’Ohio??? Les états esthètes de Flex4

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

Si ce n’est déjà fait, je vous laisse jeter un œil sur la première partie de cette architecture, et de récupérer le swc avant de lire la suite.

A quoi ça sert l’IOC ?

L’IOC ( Inversion Of Control ) est un patron d’architecture, possédant plusieurs représentations ( inversion de contrôle, injection de dépendance, …). Je ne vais pas faire un cours sur l’Injection de contenu : je vous laisse voir ici pour plus d’informations.

Dans Reflex, le but du package IOC est de décentraliser les objets de configurations de l’application. En gros, mettre les services d’accès aux données dans un fichier de configuration XML au lieu de les coder en dur dans l’application Flex.

Certains spécialistes me diront certainement que l’Injection de contenu n’est pas forcement une représentation de l’IOC, et donc un abus de langage pour Reflex : je répondrais par “traduisez ici IOC par Injection Of Content, et laissons tomber les patrons d’architecture !”.

Au commencement, le ServicesLocator

Nous avons vu dans la première partie comment réaliser simplement un appel à une méthode distante. Avoir un point d’accès global aux différents services est pratique lorsque l’on commence à avoir plusieurs services, ou si des vues différentes utilisent un service identique. Voyons comment procéder avec le premier exemple.

Reprenons l’exemple du tuto #1 : il faut charger les services dans le ServicesLocator. Nous allons donc modifier notre vue :

<?xml version="1.0" encoding="utf-8"?>
<mx:Application
	xmlns:mx="http://www.adobe.com/2006/mxml"
	layout="absolute"

	creationComplete="init()"

	xmlns:controller="controller.*"
	xmlns:model="model.*">

	<mx:Script>
		<![CDATA[
			import com.lafabrick.reflex.service.ServicesLocator;

			public static const SERVICE_USER:String = "userService";
			public static const SERVICE_OTHER:String = "otherService";

			private function init() : void
			{
				ServicesLocator.addService( SERVICE_USER, remoteUser );
				ServicesLocator.addService( SERVICE_OTHER, remoteOther );

				userControl.service = ServicesLocator.getService( SERVICE_USER );
			}

		]]>
	</mx:Script>

	<mx:RemoteObject id="remoteUser"
		destination="javaFacadeUser" showBusyCursor="true" />

	<mx:RemoteObject id="remoteOther"
		destination="javaFacadeOther" showBusyCursor="true" />

	<controller:UserController id="userControl" />

	<model:UserModel id="userModel" />

	<mx:VBox>
		<mx:TextInput id="login" />
		<mx:TextInput id="password" displayAsPassword="true" />

		<mx:Button label="connect"
			click="{userControl.login(login.text, password.text)}" />

		<mx:Label x="208" y="44"
			text="User Name : {userModel.userLogged.name}"/>
	</mx:VBox>

</mx:Application>

• À la création de l’application ( creationComplete ), nous déclenchons la fonction init();.
• Nous ajoutons les services RemoteObject dans le ServicesLocator. La signature de cette méthode est la suivante :

  ServicesLocator.addService( serviceName:String, serviceObject:AbstractService )
  

   

  • 



serviceName:String est le nom de référence utilisé pour indexer, et plus tard retrouver le bon service.
  • serviceObject:AbstractService est l’identifiant (id) de l’object service (le RemoteObject).

• Nous supprimons la propriété service dans la déclaration mxml de UserController, pour la déclarer en ActionScript dans la fonction init(). 

ServicesLocator.getService( serviceName:String ) renvoie l’instance du service défini par serviceName, référencée dans le locator.

Note : Au niveau de l’appel du service, nous pourrions appeler la méthode getController de ControllerLocator.

userControl.login(login.text, password.text);


devient :

( ControllerLocator.getController( MonApplication.SERVICE_USER )
	as UserController ).login(login.text, password.text);

Dans ce cas, nous devons « caster » le retour de getController(…) en UserController ( sinon erreur ! Flex ne connaîtrait pas la méthode login )

Un composant pour la vue

Histoire de mettre en pratique un peu plus l’utilisation des “locators” de Reflex, nous allons créer un composant MXML étendant Canvas, qui va contenir la représentation visuelle de notre application. Nous allons utiliser ControllerLocator dans ce fichier pour récupérer le UserController.

<?xml version="1.0" encoding="utf-8"?>
<mx:Canvas
	xmlns:mx="http://www.adobe.com/2006/mxml"
	width="100%"
	height="100%">

	<mx:Script>
		<![CDATA[
			import model.UserModel;
			import controller.UserController;
			import com.lafabrick.reflex.controller.ControllerLocator;
			import com.lafabrick.reflex.model.ModelLocator;

			[Bindable]
			private var userDataModel:UserModel =
				( ModelLocator.getModel( UserModel ) as UserModel);

		]]>
	</mx:Script>

	<mx:VBox horizontalCenter="0" verticalCenter="0">
		<mx:TextInput id="login" />
		<mx:TextInput id="password" displayAsPassword="true" />

		<mx:Button
			label="connect"
			click="{ ( ControllerLocator.getController( UserController )
				as UserController ).login( login.text, password.text )}" />

		<mx:Label x="208" y="44"
			text="User Name : {userDataModel.userLogged.name}"/>
	</mx:VBox>

</mx:Canvas>

Pour que le “Binding” fonctionne correctement entre la vue et le modèle, nous devons utiliser des pointeurs vers les modèles à utiliser.

Le fichier de configuration XML (IOC)

Nous venons de voir comment utiliser le ServiceLocator. Intégrons maintenant le système IOC pour ne plus avoir à le gérer !

Ce fichier vous permet de décrire des objets, pour ensuite les récupérer et les instancier dans votre application ( via ApplicationContext ). Ce fichier s’inspire fortement des fichiers de configuration de Spring, un framework puissant pour Java.

Ci-dessous le fichier représentant 2 services RemoteObject :

<?xml version="1.0" encoding="UTF-8"?>
<objects>

	<object id="remotingUser" className="mx.rpc.remoting.mxml.RemoteObject">
		<property name="destination" className="String">javaFacadeUser</property>
		<property name="showBusyCursor" className="Boolean">true</property>
	</object>

	<object id="remotingOther" className="mx.rpc.remoting.mxml.RemoteObject">
		<property name="destination" className="String">javaFacadeOther</property>
		<property name="showBusyCursor" className="Boolean">true</property>
	</object>

</objects>

• Le tag <objects> englobe les différents objets définis dans le fichier. Il est défini par :
• Un objet <object> est défini par :
  • un identifiant id. Cet id est celui que nous utiliserons plus tard dans l’application Flex pour retrouver et instancier l’objet.
  • un nom de classe className : la classe de référence.
• Les propriétés des objets sont définies par :
  • leur nom name
  • leur classe className de référence.

Ici, un RemoteObject a besoin de 2 propriétés : la destination du type String, et éventuellement showBusyCursor du type Boolean.

Régler le problème d’inclusion de classe

Le “petit” problème de ce système est que la déclaration externe des objets fait que les classes ne sont pas intégrées dans le projet Flex. Le compilateur Flex ne trouve pas de référence aux classes, et ne les intègre donc pas dans la compilation. Un façon très simple de régler ce problème est de créer un petit fichier actionScript, et d’ajouter des objets bidons du même type que ceux définis dans votre fichier de config.

Exemple avec les services : (fichier includeService.as)

import mx.rpc.http.mxml.HTTPService;
import mx.rpc.remoting.mxml.RemoteObject;
import mx.rpc.soap.mxml.WebService;

private var ser1:RemoteObject;
private var ser2:HTTPService;
private var ser3:WebService;

Ce fichier sera intégré dans votre application.

Chargement et gestion du contexte XML

Vous allez voir : simple comme bonjour !
Nous allons ajouter le chargement du fichier via ApplicationContext. ApplicationContext permet de charger automatiquement le contexte cible, et de retrouver, instancier, et enregistrer automatiquement tous les services qui se trouvent dans votre fichier de configuration XML dans le ServicesLocator.

Votre application finale :

<?xml version="1.0" encoding="utf-8"?>
<mx:Application
	xmlns:mx="http://www.adobe.com/2006/mxml"
	layout="absolute"

	creationComplete="init()"

	xmlns:model="model.*"
	xmlns:view="view.*"
	xmlns:controller="controller.*"
	xmlns:service="service.*">

	<mx:Script>
		<![CDATA[
			import com.lafabrick.reflex.ioc.event.ContextEvent;
			import com.lafabrick.reflex.ioc.ApplicationContext;
			import com.lafabrick.reflex.controller.ControllerLocator;
			import com.lafabrick.reflex.service.ServicesLocator;

			include "includeService.as"

			private function init() : void
			{
				ApplicationContext.addEventListener(
					ContextEvent.CONTEXT_LOADED, onLoaded );

				ApplicationContext.load( "ioc/application-config.xml" );
			}

			private function onLoaded( event:ContextEvent ) :void
			{
				// Contexte chargé
				// ...
			}

		]]>
	</mx:Script>

	<controller:UserController id="userControl" />

	<model:UserModel id="userModel" />

	<view:LoginView id="view" />

</mx:Application>

• Nous continuons à utiliser le “creationComplete” pour déclencher la fonction init() qui chargera le fichier de configuration.
• Il ne faut pas oublier d’inclure au besoin les classes contenues dans notre fichier de config !

  include "includeService.as"
  

• Dans la fonction init(), nous ajoutons un écouteur sur ApplicationContext (ContextEvent.CONTEXT_LOADED), qui déclenchera la fonction onLoaded quand le fichier de configuration sera chargé. Puis nous lançons le chargement du fichier de config ( ioc/application-config.xml ).
• … Et nous incluons la vue LoginView.

Modification de notre UserController

Dans un soucis de clarté, nous allons créer 2 classes contenants les constantes référençants les noms des services (contenus dans le fichier de configuration), et les noms des méthodes de ces services.

MethodConstant (dans notre exemple uniquement la méthode login)

package service
{
	public class MethodConstant
	{
		public static const LOGIN:String = "login";
	}
}

ServiceConstant (les identifiants des objets contenus dans le fichier de configuration)

package service
{
	public class ServiceConstant
	{
		public static const SERVICE_USER:String = "remotingUser";
		public static const SERVICE_OTHER:String = "remotingOther";
	}
}

Nous venons de charger notre fichier de configuration au niveau de notre Application. Nous devons maintenant modifier notre contrôleur pour qu’il écoute le chargement du fichier (événement ContextEvent.CONTEXT_LOADED), et mette à jour sa propriété service.

package controller
{
	import com.lafabrick.reflex.controller.BaseController;
	import com.lafabrick.reflex.ioc.ApplicationContext;
	import com.lafabrick.reflex.ioc.event.ContextEvent;
	import com.lafabrick.reflex.model.ModelLocator;
	import com.lafabrick.reflex.service.ServicesLocator;

	import dataObject.UserDo;

	import model.UserModel;

	import mx.rpc.events.FaultEvent;
	import mx.rpc.events.ResultEvent;

	import service.MethodConstant;
	import service.ServiceConstant;

	public class UserController extends BaseController
	{

		public function UserController() : void
		{
			ApplicationContext.addEventListener(ContextEvent.CONTEXT_LOADED, onLoaded);
		}

		private function onLoaded( event:ContextEvent ) :void
		{
			// Contexte chargé
			this.service = ServicesLocator.getService( ServiceConstant.SERVICE_USER );
		}

		public function login( log:String, pass:String ) : void
		{
			executeMethod(MethodConstant.LOGIN, onLoginResult, onLoginFault, log, pass);
		}

		public function onLoginResult( event:ResultEvent ) : void
		{
			(ModelLocator.getModel( UserModel ) as UserModel).userLogged =
				event.result as UserDo;

			trace((ModelLocator.getModel( UserModel ) as UserModel).userLogged.name);
		}
		public function onLoginFault( event:FaultEvent ) : void
		{
			trace("resultat pourri ..."+event.fault);
		}

	}
}

Les sources de cette exemple

Et voilà ! Je vais préparer d’autres articles, notemment l’intégration de Reflex dans un projet Gumbo/Flex4. N’hésitez pas à poster vos retours, c’est en flexant qu’on devient flexeron.Autres articles sur le même sujet

• Utiliser Cairngorm dans un projet Flex / AMFPHP
• Google AJAX Language API… et ton Flex devient polyglotte !
• Reflex #1: une micro-architecture pour Flex… simple !
• Flex 4 et les layouts – Faire une ViewStack « pure » Spark

Let’s gamble !

Encore un MVC ?

Oui.
Plus sérieusement, l’écriture de cette micro-architecture est partie d’un besoin de simplicité et de robustesse.

Souvent dans le monde de Flex, les équipes ne sont pas forcement homogènes. Certains sont habitués à la rigueur de Java, d’autres sont plus “devsigners freestyle” venant du monde Flash. Les premiers aiment les grosses mécaniques comme PureMVC, ou Prana Framework “Spring like”. Les seconds connaissent au mieux Cairngorm, au pire confondent MVC et VMC – ce qui n’a rien a voir, sauf si vous faites une application riche sur le thème de la ventilation.
Il fallait donc trouver la solution la plus efficace pour avoir un flux de production le plus optimal.

Bon vous me direz “ba Cairngorm c’est pas mal” ! Oui mais voilà. Cairngorm est plus une ligne de conduite qu’une micro-architecture. Il suffit en gros de suivre les interfaces et d’écrire son MVC. C’est simple, mais pourquoi diable utiliser ces #?~! d’événements synchrones pour déclencher des commandes ! Et il devient assez pénible de dupliquer le travail déjà fait côté serveur… sans compter le temps de compilation à rallonge. C’est rigolo pour se faire les dents, mais au bout d’un moment faut être sérieux.

Donc Reflex.

Le MVC en 2 mots

MVC, pour Model View Controller, est le design pattern le plus connu. Le but de ce pattern est de décomposer la représentation graphique (la vue), la couche métier et le modèle de données.

Le modèle MVC de Reflex peut se visualiser comme suit :

• La vue demande au contrôleur la récupération de données.
• Le contrôleur lance la méthode avec les arguments associés, et capte les retours du serveur.
• À la réception des données, le contrôleur met à jour le modèle de données.
• Le modèle notifie à la vue son changement et la met à jour.

Préparation de votre projet d’exemple

Une page de ressources pour Reflex est disponible sur le Blog.

Commencez par récupérer le swc reflex.
Les sources, et la documentation sont aussi disponibles en lignes.

Pour cette exemple, nous allons utiliser un petit service Java. Je vous laisse télécharger le projet d’exemple “reflexTuto1”, et regarder :

• le répertoire “java” : les sources Java ( UserDo : l’object de donnée, UserDs : la couche métier ).
• Les fichiers de configuration dans le répertoire WebContent/WEB-INF/flex/remoting-config.xml : la configuration des services distants.

Pour cette exemple vous aurez besoin d’un environnement Flex avec les WTP installés ainsi qu’un serveur Tomcat (pour lancer les exemples).

Petit rappel :

• Pour installer les WPT ( qui vous donne accès à la perspective J2EE et à la vue server) :
  • Ouvrez le menu Help > Software updates > Find and install…
  • Faites “Search new features to install”
  • Dans la fenêtre qui apparaît, cochez “Europa Discovery Site”
  • Cliquez sur “Finish”
  • La recherche de plugins commence. Vous devrez choisir votre miroir. La fenêtre de résultats s’affiche. Déployez “Europa Update Site” et cochez “Web and J2EE Development”
  • Cliquez sur le bouton “Select Required”
  • Faites “Next”
  • Cochez “I accept…”
  • Faites “Next” de nouveau
  • Faites “Finish”
• Pour installer un serveur TOMCAT
  • Téléchargez un Tomcat 6
  • Décompressez l’archive dans le répertoire de votre choix
  • Vous devez configurer votre serveur dans Flex à partir de la vue Server : « Windows > Other View… » puis « Servers« 
  • Un fois configuré (clic droit dans la vue servers et « New…« ), n’oubliez pas d’ajouter votre projet sur votre serveur ! (clic droit dans la vue servers et « Add and remove projects…« )

Au départ : un service et un objet de données

Tout d’abord nous devons représenter l’objet de données du serveur dans votre projet.

L’objectif est d’avoir une image identique des données côté serveur et côté Flex, afin que les 2 parties “parlent la même langue” : cette classe contient une référence vers son “image” côté serveur.

package dataObject
{

	[Bindable]
	[RemoteClass(alias="User.UserDo")]
	public class UserDo
	{
		public function UserDo()
		{
		}

		public var login:String;
		public var name:String;

	}
}

Nous voulons discuter avec la couche server : nous allons donc utiliser un service de type RemoteObject, faisant référence à notre couche serveur, défini dans le fichier remoting-config.xml.

<mx:RemoteObject
	id="remoteUser"
	destination="javaFacadeUser"
	showBusyCursor="true" />;

Le Modèle

Le modèle est notre réceptacle de données.
Cette classe étend BaseModel, qui permet l’enregistrement automatique du modèle dans le ModelLocator.
C’est lui qui sera mis à jour par le contrôleur, et qui, via le tag [Bindable], mettra a jour là vue. Dans notre exemple nous allons stocker le UserDo, résultant de la requête serveur login().

package model
{
	import com.lafabrick.reflex.model.BaseModel;

	import dataObject.UserDo;

	public class UserModel extends BaseModel
	{
		[Bindable]
		public var userLogged:UserDo;

	}
}

Le Contrôleur

C’est l’intelligence du système. C’est lui qui invoque le service, récupère et met à jour les données.

package controller
{
	import com.lafabrick.reflex.controller.BaseController;
	import com.lafabrick.reflex.model.ModelLocator;

	import dataObject.UserDo;

	import model.UserModel;

	import mx.rpc.events.FaultEvent;
	import mx.rpc.events.ResultEvent;

	public class UserController extends BaseController
	{

		public function login( log:String, pass:String ) : void
		{
			executeMethod( "login", onLoginResult, onLoginFault, log, pass);
		}

		public function onLoginResult( event:ResultEvent ) : void
		{
			(ModelLocator.getModel( UserModel ) as UserModel).userLogged =
				event.result as UserDo;
		}

		public function onLoginFault( event:FaultEvent ) : void
		{
			trace("Bad result ..."+event.fault);
		}
	}
}

• Cette classe étend BaseController, qui permet l’enregistrement automatique du contrôleur dans le ControllerLocator.
• La méthode login() contient la mécanique de déclenchement du service (méthode de BaseController). La méthode executeMethod est définie par les propriétés suivantes :
  • method:String : le nom de la méthode ( “login” ),
  • resultFunction:Function : la fonction déclenchée lorsque le serveur renvoie un résultat (onLoginResult)
  • faultFunction:Function = null : la fonction déclenchée lorsque le serveur renvoie une faute (onLoginFault)
  • … args : tous les arguments à passer à la méthode distante…
• Le modèle est mis à jour dans le fonction de résultat. Pour récupérer l’instance du modèle, il suffit d’utiliser le ModelLocator :

  // Renvoie l'instance UserModel enregistré dans ModelLocator
  trace( ( ModelLocator.getModel( UserModel ) as UserModel ) );
  

NOTE : les “locator” ModelLocator et ControllerLocator n’enregistrent qu’une et une seul instance d’un même modèle / contrôleur. Si deux instances d’un même modèle / contrôleur sont déclarées, une erreur ReflexError est levée. Les classes étendant BaseController et BaseModel sont automatiquement référencées dans ModelLocator et ControllerLocator.

La Vue

Construisons maintenant notre vue.

<?xml version="1.0" encoding="utf-8">
<mx:Application
	xmlns:mx="http://www.adobe.com/2006/mxml"
	layout="absolute"
	xmlns:controller="controller.*"
	xmlns:model="model.*">

<mx:RemoteObject
	id="remoteUser";
	destination="javaFacadeUser";
	showBusyCursor="true" />

	<controller:UserController id="userControl" service="{remoteUser}" />

	<model:UserModel id="userModel" />

	<mx:VBox>
		<mx:TextInput id="login" />
		<mx:TextInput id="password" displayAsPassword="true" />

		<mx:Button label="connect"
			click="{userControl.login( login.text, password.text )}" />

		<mx:Label x="208" y="44"
			text="User Name : {userModel.userLogged.name}"/>;
	</mx:VBox>

</mx:Application>

• Nous créons une instance RemoteObject permettant de pointer sur le service côté serveur. La propriété destination est l’identifiant du service dans le fichier remoting-config.xml.
• Nous créons une instance de UserController, avec comme propriété service l’identifiant du RemoteObject “remoteUser”.
• De la même manière, nous créons l’instance du modèle UserModel.
• Au final, la vue appel la méthode login() du contrôleur, qui se charge d’envoyer et de réceptionner les données au serveur. Au retour, le contrôleur met à jour le modèle, en “poussant” le UserDo provenant du serveur. La vue est automatiquement mise à jour via le principe de Binding des données.

Les sources de cette exemple

Conclusion

Reflex n’a pas la prétention de concurrencer des architectures reconnues comme PureMVC ou MATE. L’objectif, vous l’aurez compris, est d’aller à l’essentiel, sans se perdre dans la forêt des Design Pattern, pour une productivité la plus efficace possible. A vous d’implémenter cette architecture selon vos besoins.

Le prochain tutoriel ira un peu plus loin dans cette micro-architecture : comment mieux découper son projet, et comment associer un fichier de configuration XML externe (package IOC).

J’attends vos retours !Autres articles sur le même sujet

• Utiliser Cairngorm dans un projet Flex / AMFPHP
• Google AJAX Language API… et ton Flex devient polyglotte !
• Reflex #2 : vous reprendrez bien un peu de IOC ?
• Flex 4 et les layouts – Faire une ViewStack « pure » Spark