Vous vous souvenez peut-être de

Il y a quelques temps, suivant les travaux de Philippe Elsass (@elsassph) sur les algos de dessin, j’ai entrepris de nouveaux travaux sur le sujet. Dans une librairie de primitives pour Flex4 d’abord, avec UIGFX, et puis rapidement pour rendre plus… « fluides » mes skins d’application, façon Neave.

Attention : parcequ’il y a de nombreux exemples, et parceque ce billet est un voyage dans le monde merveilleux de la gelée; votre ordinateur peu subir quelques changements et râler un peu

Ceux qui me suivent sur Twitter auront peut-être vu passer quelques essais.

(Clic pour ouvrir)
Ces tests de skinning flex interactif proviennent d’une extension Fluide de la librairie UIGFX (extension que je n’ai pas encore diffusé, faute de temps…)

BIGA! Nicolas Barradeau (@nicoptere) nous lance une série d’articles impressionnante sur l’art génératif, qui ce termine par une lib d’outils géométrique : Biga. J’ai pas pu me retenir, et repris mes expérimentations.

Des points…

L’idée de l’interaction «fluide» est basé sur les algo de répulsion. Lorsque qu’un point de souris approche d’une zone d’interaction de point de vecteur, il faut calculer une «dispersion» du point.

J’utilise 2 facteurs distincts :

• La viscosité: un coefficient qui donne, comme son nom l’indique, la viscosité du point. En physique des fluides, la viscosité représente la capacité d’un liquide à s’écouler. Plus le coefficient est faible, plus l’écoulement du fluide est rapide (ex: l’eau). A l’inverse, plus le coefficient est élevé, plus le fluide à des contraintes physiques importantes qui réduisent sont écoulement (ex.: la confiture).
• le facteur de gelée: c’est mon coefficient «maison». Un indicateur qui permet de préciser le degré de déformation d’un fluide. Plus ce facteur est élevé, plus le taux de déformation, et donc le mouvement de la forme, sera important.

En AS3, on peut l’écrire comme ceci :

public function update(owner:DisplayObject):void
{
offsetx+=(xref - x) / jelly;
offsety+=(yref - y) / jelly;

var dx:Number=0;
var dy:Number=0;
if (owner.stage)
{
dx=x - owner.stage.mouseX;
dy=y - owner.stage.mouseY;
}

if (Math.sqrt((dx * dx) + (dy * dy)) <= approach * 1.1)
{
var divisor:Number=approach / 10;
var a:Number=Math.atan2(dy, dx);

offsetx+=(Math.cos(a) * approach - dx) / divisor;
offsety+=(Math.sin(a) * approach - dy) / divisor;
}

offsetx*=(1 - viscosity);
offsety*=(1 - viscosity);
if (Math.abs(offsetx) < .001)
{
offsetx=0;
}

if (Math.abs(offsety) < .001)
{
offsety=0;
}

x+=offsetx;
y+=offsety;
}

Visuellement :

…Des lignes…

2 points définissent une ligne… C’est la règle.

Projection

Pour obtenir une ligne «fluide», il faut avoir un point de vecteur intermédiaire sur la ligne.
Une méthode simple et efficace est de projeter le point de la souris sur la ligne. Les mathématiciens on depuis longtemps résolu le problème, et l’implémentation AS3 d’un algo de projection ressemble à ça :

public static function projection(p:Point, a:Point, b:Point):Point
{
var len:Number = length(a, b);
var r:Number = (((a.y - p.y) * (a.y - b.y)) - ((a.x - p.x) * (b.x - a.x))) / (len * len);

var px:Number = a.x + r * (b.x - a.x);
var py:Number = a.y + r * (b.y - a.y);

return new Point(px, py);
}

Avec les outis géométriques proposés par @nicoptere dans la lib Biga, le point de projection contraint dans la ligne, peut se calculer comme suit :

var mousePoint : Point = new Point(mouseX, mouseY);
var projection : Point = GeomUtils.project(mousePoint, point1, point2);
var constraintProjection : Point = GeomUtils.constrain( projection, point, point2);

La projection du point de souris sur notre ligne molle nous permet d’obtenir une interaction intéressante :

Si les points d’origine sont fixes, vous obtenez une espèce de corde de guitare. Rigolo.

…Et des formes

Avec encore plus de points on commence a avoir des formes, façon gateau anglais :

Un autre exemple intéressant qui reprend la simulation de Philippe Elsass :
(Clic pour ajouter un point, Ctrl/Cmd + click pour supprimer un point)

Encore plus de gelée

Comme je le disais au début de cette article, nous travaillons depuis quelques temps sur une librairie de primitives pour Flex4 : UIGFX. L’idée est de proposer une suite de primitives bien utiles, qui n’existent en standard dans le SDK Flex4 (lignes pointillées, arc, camembert, ….).

Dans cette librairie, nous avons mis en place une primitive de représentation graphique de path SVG, qui, à la différence de la primitive Path standard du SDK Flex, permet de placer les vecteurs dans le modèle de contraintes top, left, bottom, right. Cette primitive permet aussi d’importer un chemin SVG, et de le convertir au format propre à cette primitive.

En modifiant un peu le parseur SVG de UIGFX, nous pouvons facilement parcourir un path SVG et extraire les points de vecteur clefs de la forme. L’idée, vous vous en doutez est de gélifier la forme

Sources et ressources

• Vous trouverez l’ensemble des sources dans ce zip
• Biga, geometric tools library
• La série d’articles de Nicolas Barradeau
• « Parametric path drawing » de Philippe Elsass
• Et bien sur le site web de Paul Neave, … et l’ancien

Have fluid’s fun !Autres articles sur le même sujet

• Dessine moi Final Fantaisy…
• La manette Wii sur mac / pc… enfin presque
• Librairie lafabrick : parce que je le vaut bien
• et le 9ème jour il créerent le volume … 2.0

L’accouchement s’est bien passé, et les 3 papas sont en pleine forme.

Autres articles sur le même sujet

• Les blogs c’est bien!… mais y a mieux !!!
• Virtual Cabinet, flash et interfaces riches pour l’apprentissage des langues (1)
• Thanks Adobe, U certified me !!!
• FITC#09 : TwiiDee, WiiFlash and Rock ‘n’ Roll

Voilà quelques temps que nous nous activions sans donner de nouvelles…, il est temps de corriger tout ça.
Aussi, pour démarrer cette nouvelle année du bon pied, La Fabrick vous propose une petite application de génération de code AS3 à partir d’un schéma XSD.

Ce petit outil nous a été utile pour pas mal de projets développés pour nos premiers clients, alors pourquoi ne pas vous en faire profiter ? Peut-être deviendrez-vous aussi MdaME-addict ?

Retrouvez toutes les infos sur http://mdame.lafabrick.comAutres articles sur le même sujet

• API de dessin en AS3
• Crée ton navigateur perso avec 5 lignes de code !
• Flex Builder 3 et le PHP ( PDT ) : installation
• Skiner un composant Flex 3 avec Fireworks CS3 [Tutoriel Vidéo]

Cette application propose un moyen simple de packager vos extensions CS5 développées avec le nouveau SDK Creative Suite.

Les extensions ZXP

Depuis la CS5, Adobe propose un nouveau SDK de développement et un format d’extension commun a toute la suite logicielle.
Ce SDK, disponible ici, vous permet de développer vos propres panneaux et autres menus CS5. Le premier format de sortie est le MXP, toujours disponible, vous permettant d’exporter votre extension pour un logiciel cible.
Maintenant, avec la CS5, vous disposez d’un format commun, le ZXP, qui rend compatible votre extension avec toutes la suites CS.

Un fichier ZXP est défini par un manifeste xml, définissant le fonctionnement de l’extension (type, portée logiciel, …), et contient le (les) SWF de l’extension (une extension est en fait une pseudo application AIR, basée sur le SDK CS). Un fichier ZXP est signé numériquement. Vous devez donc avoir un certificat (PKCS12, PKCS11, JKS). Vous pouvez bien entendu utiliser votre certificat auto-signé préalablement créé avec Flash/Flex Buider.

Pour plus d’informations :

• Creative Suite SDK
• le blog CSSDK

Un fichier ZXP doit (habituellement) être compilé en utilisant le packager Java UCF. Et c’est là l’idée de cette petite application : ne pas avoir a redéfinir vos certificats et autres options pour chaque package, et vous proposer une interface plus « user friendly » que le terminal.

Fonctionnement

Démarrage, et préférences

Au premier démarrage, l’application doit obtenir vos préférences de base.

• Java Home

  Vous devez indiquer le chemin vers votre JDK/JRE java, si celui-ci ne correspond pas à celui par défaut (l’application intègre le packager jar UCF, et elle doit connaître le répertoire racine de Java pour pouvoir le lancer). Les chemins racines par défaut sont:

  • Pour Windows : ‘C:\Program Files\Java\jdk1.6.0′
  • Pour Mac : ‘/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0′

• Certificat

  Vous devez préciser l’emplacement de votre certificat (généralement un fichier de type .p12 ou .p11), ainsi que votre mot de passe. Ces informations sont nécessaires pour la signature de l’extension.

  • Fichier cible

    Vous devez indiquer le fichier de destination. L’extension .zxp est ajoutée automatiquement.

  • Source de l’extension

  Les sources de l’extension, comme défini dans la nomenclature du SDK CS, doivent correspondre à ce schéma:

  
  Ce répertoire est construit préalablement par la tâche ant de compilation, dans votre projet (cf. en fin d’article, le téléchargement du projet test d’extension)
  Vous devez pointer sur le répertoire « bin ».

  • Démarrer un nouveau package;
  • Ouvrir et installer l’extension via Extension Manager (vous devez bien entendu avoir préalablement installé Extension Manager CS5)
  • Projet fxp
  • Archive zip du bin de test

Définition de votre extension

Un package ZXP a besoin de 2 informations : le nom et l’emplacement de votre extension cible, et l’endroit où se trouve le répertoire « bin » de votre extension.



Une fois le packaging démarré, un message d’attente s’affiche.



Finalisation

Une fois le package créé, l’application vous propose de :



Téléchargements

ZXPackager

Extension de test

Autres articles sur le même sujet

• [Flex 3 Beta] bug : Application File doesn’t exist
• Un projet Java / Flex avec Maven 2
• AIR 2 : appeler un JAR exécutable via un NativeProcess
• RollingFileTarget pour AIR 2.0 : let’s roll !

Let’s rock n’ roll…
Autres articles sur le même sujet

• La Fabrick … ou quand Fabien rencontre Erick
• Noël avant l’heure : la journée de la béta 2 sur Labs.adobe.com
• ZXPackager : application pour l’empaquetage ZXP d’extensions CS5
• Ça envoie…

Que vous soyez acteurs dans les nouvelles technologies ou simplement curieux de voir ce que le présent nous réserve, vous êtes conviés à venir participer au 1er BarCamp dédié aux Interfaces Riches, le 23 juin 2010 à partir de 17h, au cyberCafé du campus de la Doua à Villeurbanne.

Au programme : des conférences, des ateliers et des démonstrations de ces technologies naissantes ou déjà matures et de leurs usages dans différents domaines (commerce, enseignement, divertissement…). Aux côtés des principaux innovateurs de ce secteur, vous pourrez même, si vous le souhaitez, proposer votre propre présentation dans les tribunes libres prévues à cet effet.

Quelques présentations au menu :

• Nouvelles expériences utilisateurs multi-canal grâce aux RIA (ipTv, bornes interactives);
• OpenScales: client cartographique basé sur les technologies ActionScript3 / Flex / AIR;
• Comment développer une RIA moderne en Javascript avec RESTHub.

Rendez vous, donc, le 23 juin 2010 pour une rencontre conviviale qui vous donnera l’occasion de découvrir ou de montrer dès aujourd’hui, les interfaces de demain.

• « Flash In The Can » : hymne a l’AS3
• Virtual Cabinet, flash et interfaces riches pour l’apprentissage des langues (3)
• Interfaces tangibles : le futur du multitouch
• Barcamp Lyon : Mix-IT, Flex, Java, PHP, JS, Cloud… (et chips)

Bien le bonsoir,
on avait imaginé une cinquième édition des Serious Drink complétement serious pour le coup… annoncée plusieurs semaines à l’avance… avec un videoproj, des beaux thèmes PowerPoint, des chips, des olives, et quelques rythmes neojazzy en interlude entre chaque présentations… la sseuclaaa !
mais bon le temps a passé, tout était bien parti… sauf les « invitations »… toujours pas parties elles… tanpis , on a quand même soif !!!
Du coup on a une petite salle réservée, mais trève de sérieux, on garde le thème classique :

Soirée Bière et fleeex donc au 1er étage du Café Cousu Jeudi le 23 d’avril à partir de 19h30 !!!
Viendez y !!!

Passage Thiaffait
19,rue René Leynaud
69001 Lyon
Tel: 04 72 98 83 38

Voir où que c’est sur une carteAutres articles sur le même sujet

• Climatus et lafabrick sur le petit écran….
• 3 minutes pour sauver vos futurs présentations…
• L’université Lyon1 cherche (aussi) 2 stagiaires
• Serious Drink 0.09.01.08…

Autres articles sur le même sujet

• Buzz à Max…
• retour sur Lafabrick @ max
• wiiFlash et 3d à l’université
• wiiFlash à l’université : acte 2

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