DEJA-VUE.NET » Application Architecture

Workshops – Méthodologie de développement IoC made in Pixlib, de LowRA à PalmER

admin — Wed, 17 Mar 2010 13:28:29 +0000

Translate original post with Google Translate

Je vous annonce une série de Workshop (de programme identique) consacrée à la méthodologie du développement IoC made in pixlib *. Les sessions auront lieu les Samedis 1, 8, 15 et 29 du mois de Mai.

Ces sessions de travail sont destinées aux développeurs AS3 débutants ou déjà familiarisés avec LowRA ou PalmER souhaitant maitriser le développement IoC.

Ce workshop se veut agnostique quant aux branches existantes (LowRA AS3/FP9 et Palmer AS3/FP10). J’insiste bien sur ce point, le workshop ne portera pas sur l’étude de telle ou telle partie concrète de l’API. Il s’agira de vivre la construction d’une application Pixlib et d’assimiler la technique du développement IoC.

Les thèmes abordés seront les suivants:

- système événementiel et architecture MVC/ IoC
- structure d’une application IoC et communication entre les plugins
- création et déploiement de plugins (tâches Ant et compilations MXMLC)
- point de montage IoC avec le(s) context.xml (structure et principes de configuration)

A l’issue de cette journée vous aurez appris à systématiser la création de projets pixlib et serez à même de développer une application IoC. Vous aurez acquis la méthodologie et les techniques qui vous permettront de vous engager dans des créations évolutives et des développements collaboratifs.

Tarif/personne: 400€ HT
Horaires : 10h30 -13H00, 14h-18h00 (horaires permettant un aller-retour dans la journée)
Date : 1, 8, 15 et 29 du mois de Mai
Lieu : Nantes
Nombre de participants : 2>5
Niveau requis: pratique de l’AS3, expérience en POO/ MVC

Si vous êtes intéressé, merci de retourner ce formulaire d’inscription rempli.

* pixlib est le domaine qui rassemblera prochainement les différentes branches du Framework

ActionStep (plugin View) / Pixlib (MVC FrontController + Remoting) SUSHI Service

admin — Thu, 25 May 2006 10:06:58 +0000

Translate original post with Google Translate

Le chef est de retour ^^. Au menu Sushis et MVC "on steroids".

Montez votre application en MVC. Une fois que le MVC a bien pris, truffez-le d'un FrontController. Parsemez avec quelques MovieClipHelpers. Arrosez finalement le tout avec, selon le choix et l'humeur, un ModelLocator et/ou un ServiceLocator...

Pixlib Remoting SUSHI service ? J'en entends déjà certains dire: il fait dans le recyclage intensif le gars...

Dans cet article je vais vous introduire à un joyau de Pixlib (il y en tellement...c'est une vraie caverne d'Ali Baba !).
SUSHI service repose sur une recette applicative incroyablement puissante et polyvalente basée sur le pattern MVC. "Recette" car ce sont bien des ingrédients qui sont mis à notre disposition. Selon ces ingrédients et l'inspiration on pourra, par exemple, faire gonfler notre MVC traditionnel en MVC à multiples Models (ModelLocator) ou bien comme c'est ici le cas, faire lever le tout en "Super MVC" (FrontController et ServiceLocator).

sushiService.zip (250)

- L' User Interface

C'est toujours du ActionStep (j' aurai bien voulu tester ASWing but no time):
Cette fois-ci, les "forms" ou "states" sont regroupés dans un module swf autonome chargé au runtime dans l'application principale. Adopter ce design a supposé une nouvelle stratégie d'instantiation.

- "Un système totalement générique"

L'addition du FrontController, du MovieClipHelpers et d'un ModelLocator (classe core.Model) au pattern MVC confère à notre application un degré de modularité exemplaire. L'essentiel de cet article sera consacré à la description de ce "Super MVC". J' évoquerai les points qui, d'un point de vue personnel, m'ont semblé les plus pertinents.

- Le service Remoting

Il repose sur la version alpha du package remoting Pixlib. Il est déployé avec souplesse depuis un Singleton ServiceLocator.

Note:
le terme "state" à été employé pour désigner les différentes views contenues dans views.swf. Il n'est donc pas à prendre ici dans son sens premier "d'état" de l'application (généralement stocké dans un SharedObject, ValueObject, instance de Memento ou autre solution)

Commençons en images afin de prendre rapidemment des repères:

La structure du projet

Diagramme (maison) de la relation FrontController, MovieClipHelper, ServiceLocator & ModelLocator

L'user Interface en standalone

Désolidariser de la structure de leur précédent hôte (ARP), les différents "states" de l'application (order, viewOrders et navigation) sont de nouveau de banales sous-classes de MovieClip dépourvues de toute fonctionnalité d' eventdispatching.

Ce nouveau profil de "plugin" a supposé changer la façon d'instancier le container des différents "states" de l'interface. Importée au runtime dans un MovieClip (via GraphicLib), l'UI doit déjà être instanciée sans dépendance de _root si nous souhaitons pouvoir le connecter à chaud tel un plugin.

L'astuce ? packager les classes et procéder à l' instantiation avec SWFMILL.

La première étape donc: compiler la view

/**
* @mtasc -version 8 -swf "classes.swf" -header 390:270:60:FCFCFC -trust
*/

// Imports...

class org.actionstep.view.sushi.Application extends MovieClip
{
// MovieClip linkage
static var id = (id="__Packages.org.actionstep.view.sushi.Application")+(Object.registerClass(id,Application)?"":"");

private var navigation : MovieClip;
private var order : MovieClip;
private var viewOrders : MovieClip;
private var dataPreloader : MovieClip;

function onLoad()
{
// ActionStep theming
org.actionstep.ASTheme.setCurrent(new
org.actionstep.themes.plastic.ASPlasticTheme());

// Set the initial display state of the application
setInitialDisplayState();

// Views Instantiation (no FLA here)
navigation = attachMovie(Navigation.id,"navigation", 1);
viewOrders = attachMovie(ViewOrders.id,"viewOrders", 2);
order = attachMovie(Order.id,"order", 3);
}
// ...
}

La deuxième étape: instancier avec SWFMILL

<?xml version="1.0" encoding="iso-8859-1"?>
version="8" width="390" height="270" framerate="60">
color="#ffffff"/>
>
>
id="Application" class="org.actionstep.view.sushi.Application" import="classes/classes.swf" />
>
id="Application" name="app" x="0" y="0" depth="1" />
>
>

L'initialisation MVC

L'application principale (Application.as) est lancée de façon conventionnelle avec main().
Le Model est d'abord instancié. Notre unique vue, une sous-classe MovieClipHelper, s'abonne à l' écoute du Model. Le controller, un Singleton et sous-classe de FrontController est finalement initialisé. Le controller est le ciment de l'application. C'est lui qui va associer évènements typés et instances de commandes.

private function _init() : Void
{
var model : Model = new SUSHIExpert();
model.addListener( new SUSHIListUI() );
Controller.getInstance().init();
}

I. LES VIEWS

Chargement de la View standalone

GraphicLib et Libstack, du chargement et multichargement intelligent.
Au travers de ces 2 implementations concrètes d'AbstractLib, nos assets sont chargés et stockés avec un identifiant de type String. En l'occurence, ces identifiants sont prédéfinis sous formes de constantes accessibles en static depuis sushi.uis.UIList. Ceci permet une meilleure traçabilité du couplage entre les assets et leurs 'accesseurs'.

var gl : GraphicLib = new GraphicLib( this, 20 );
gl.setName( UIList.SUSHI_List );
gl.addEventListener( GraphicLib.onLoadInitEVENT, this, _init );
gl.load( "deploy/views.swf" );

var libs = new LibStack();
libs.enqueue(new GraphicLib(this, 20, false), UIList.SUSHI_List, "deploy/views.swf");
libs.addEventListener( LibStack.onLoadCompleteEVENT, this, _init );
libs.execute();

Les éléments sont ensuite accessibles globalement de plusieurs façons:

- Depuis le Singleton GraphicLibLocator:

var myView:MovieClip = GraphicLibLocator.getInstance().getGraphicLib( UIList.SUSHI_List ).getView();

- Depuis une sous-classe MovieClipHelper:

// SUSHIListUI.as

class sushi.uis.SUSHIListUI
extends MovieClipHelper
{
public function SUSHIListUI ()
{
super( UIList.SUSHI_List );
}
}

- Depuis une sous-classe ViewHelper

import com.bourre.data.libs.GraphicLib;
import com.bourre.visual.ViewHelper;
import sushi.uis.UIList;

class sushi.uis.SUSHIListUI
extends ViewHelper
{
public function SUSHIListUI ( gl : GraphicLib )
{
super( gl.getView(), UIList.SUSHI_List );

view.app.showDataPreloader();
gl.show();
}
}

C'est vraiment très pratique d'avoir un accès global sur les views:
Par exemple, si je souhaite déclencher une action sur une view depuis une Command:

Avec GraphicLibLocator:

import com.bourre.data.libs.GraphicLibLocator
import sushi.uis.UIList;

class sushi.commands.PlaceOrder
implements Command
{
public function execute( e : IEvent ) : Void
{
var myView:MovieClip = GraphicLibLocator.getInstance().getGraphicLib( UIList.SUSHI_List ).getView();
myView.app.orderProcessed();
}
}

avec MovieClipHelper

import com.bourre.visual.MovieClipHelper
import sushi.uis.UIList;

class sushi.commands.PlaceOrder
implements Command
{
public function execute( e : IEvent ) : Void
{
var myView = MovieClipHelper.getMovieClipHelper(UIList.SUSHI_List);
myView.view.app.showDataPreloader();
myView.traceTest(); // calling a method on SUSHIListUI
}
}

Ici, en ce qui nous concerne, Sushi service n'a qu'une seule View de type MovieClipHelper

Sur une instance de MovieClipHelper on va, typiquement:

- définir le comportement des objets (TextField, MovieClips, v2 components...) présents dans la View au moyen de leurs noms d'instances.

Dans le cas de Sushi service, l'UI ActionStep n'est pas qu'une coque vide.

La view externe possède déjà des méthodes:

hideDataPreloader();
showDataPreloader();
orderFormSelect();
viewOrdersFormSelect();

Ensuite, dans chaque "state" ( Navigation, Order, ViewOrders ), les event handlers des boutons sont déjà définis, ex.:

// NSButton
placeOrderButton = (new NSButton()).initWithFrame(new NSRect(300, 205, 80, 22));
placeOrderButton.setStringValue("Place order");
placeOrderButton.setTarget(this);
placeOrderButton.setAction("placeOrder");
view.addSubview(placeOrderButton);

C'est pas grave du tout ^^. On va piloter et arranger le scope depuis notre sous-classe MovieClipHelper

class sushi.uis.SUSHIListUI
extends MovieClipHelper
{
private function _initBehaviors() : Void
{
_pbCancelOrder.setTarget(this);
_pbCancelOrder.setAction("cancelOrder");

_dSelectViewOrders = new Delegate(view.app, view.app.viewOrdersFormSelect);
_dShowPreloader = new Delegate(view.app, view.app.showDataPreloader);
}

private function _gotoViewOrders() : Void
{
_dSelectViewOrders.execute();
_dShowPreloader.execute();
}

private function cancelOrder() : Void
{
_dShowPreloader.execute();
_fireEvent(new BasicEvent(EventList.cancelOrderEVENT, view.app.viewOrders.getOrder() ));
}
}

Une "architecture de legos" où nous avons un contrôle total sur chaque pièce autonome pluggée.

Reprenons un peu le fil.
Sur une instance de MovieClipHelper, on va aussi:

- définir les callbacks du ou des Models.
- diffuser (avec notre EventBroadcaster global) des messages de type BasicEvent ou customs (sous-classe BasicEvent) vers les commandes correspondantes.

N'hésitez pas à étendre BasicEvent afin de créer vos propres event objects. C'est une autre pierre angulaire de Pixlib.

Jetez un oeil à la méthode placeOrder(). Vous verrez qu'elle broadcaste un événement de type OrderEvent.

private function placeOrder() : Void
{
_gotoViewOrders();
_fireEvent(new OrderEvent(EventList.placeOrderEVENT, view.app.order.orderName, view.app.order.orderTicket));
}

Attention, la comparaison est malheureuse, mais c'est juste pour faire capter rapidement l'idée à ceux qui sont d'un background ARP:
Voyez OrderEvent comme un Value Object (VO) passant les informations à la commande.
Voilà , vous pouvez vous lacher et crier hérésie haut et fort ^^.

II. Le FrontController

C'est dans sushi.commands.Controller (sous-classe de FrontController) que sont associés et stockés Events et Commands. A la différence du ControllerTemplate d'ARP, le FrontController n'impose aucune référence directe sur les views. Less coupling!

FrontController:

public function init() : Void
{
push ( EventList.placeOrderEVENT, new PlaceOrder() );
push ( EventList.getOrdersEVENT, new GetOrders() );
push ( EventList.cancelOrderEVENT, new CancelOrder() );
}

ControllerTemplate:

private function addEventListeners ()
{
app.orderForm.addEventListener ( "orderPizza", this );
app.viewOrdersForm.addEventListener ( "getOrderList", this );
app.viewOrdersForm.addEventListener ( "cancelOrder", this );
}

private function addCommands ()
{
addCommand ( "orderPizzaCommand", OrderPizzaCommand );
addCommand ( "getOrderListCommand", GetOrderListCommand );
addCommand ( "cancelOrderCommand", CancelOrderCommand );
}

III. ServiceLocator et Commands

Dans le Singleton ServiceLocator nous définissons et stockons un ou plusieurs services remoting (selon nos besoins). Le nom d'alias de chaque service est défini en static.

- La définition du service remoting:

// sushi.service.ServiceLocator
public static var SUSHISERVICE:String = "dejavue_net.sushi.sushiService";

public function init( remotingURL : String ) : Void
{
gatewayURL = "http://www.deja-vue.net/amfphp/gateway.php";
push( ServiceLocator.SUSHISERVICE, ServiceLocator.SUSHISERVICE );
}

- Configuration type d'une commande:

1. Localisation du service remoting et appel et de la remote method

Attention, à l'heure où cet article est écrit, le package remoting est toujours en version alpha et non disponible depuis le svn. Je ne m' étendrai donc pas sur l'implémentation du responder ni sur l'API.

// class sushi.commands.PlaceOrder

public function PlaceOrder()
{
_service = ServiceLocator.getInstance().getService( ServiceLocator.SUSHISERVICE );
}

public function execute( e : OrderEvent ) : Void
{
_service.order( new ServiceResponder(this), e.getName(), e.getTicket() );
}

public function onResult( e : BasicResultEvent ) : Void
{

}

public function onFault(e : BasicFaultEvent) : Void
{

}

2. Tous les chemins mènent à Rome:

Là , c'est GRANDIOSE. Depuis une commande (pas seulement d'ailleurs) nous pouvons:

- appeler la view de notre choix (rappelez-vous de GraphicLibLocator, MovieClipHelper et ViewHelper).
- broadcaster un event typé et déclencher une nouvelle commande.

EventBroadcaster.getInstance().broadcastEvent( new BasicEvent(EventList.getOrdersEVENT) );

- appeler le model de notre choix.

SUSHIExpert(Model.getModel( ModelList.SUSHI_EXPERT )).onUpdate( e.getResult() );

Epoustouflant d'avoir autant de contrôle

Le mot de la fin (il est temps! ^^):

Il y a 2 jours, j' étais parti bille en tête avec l'idée de faire un papier sur le package MVC de Pixlib. En même temps, je me disais que c' était un peu léger comme sujet. C'est en approfondissant les packages events et visual que j'en suis arrivé au FrontController + MovieClipHelper et à approfondir. Pixlib n'avait pas fini de m' étonner...
Je reste bluffé. Je ne m'attendais vraiment pas ça. Devinez avec quoi je vais boulonner mon prochain projet .

Chapeau bas à Francis.

Liens de Référence:

-MVC et FrontController
http://www.tweenpix.net/blog/index.php?2004/09/22/460-whiteboard-10
Discussion about models in mvc and front controller patterns on Pixlib list

GraphicLib, LibStack et MovieClipHelper
http://www.get-url.net/blog/?47--pixlib-libstack-ou-le-multi-chargement
http://www.get-url.net/blog/?48--pixlib-graphiclib-et-moviecliphelper-vs-movieclip-parti

Open Source Flash Pizza for everyone ! follow-up – Shared Fonts

admin — Tue, 16 May 2006 19:58:55 +0000

Translate original post with Google Translate

On m'a demandé des précisions sur la technique des "polices partagées" utilisée dans OSFlash Pizza. En voici le secret...

Structure de georgia.xml

<?xml version="1.0" encoding="iso-8859-1" ?>
width="1" height="1" framerate="12">
>
>
import="src/ttf/georgia.ttf"/>
>
url="http://www.deja-vue.net/test/shared/swf/fonts/Georgia Gras.swf">>
>
>

On compile avec la ligne de commande suivante:

swfmill simple "src/georgia.xml" "deploy/Georgia Gras.swf"

Voilà !

Ensuite, libre à vous de choisir la façon de charger la police.

Dans le cas d' OSFlash Pizza j' ai choisi la voie du MovieClipLoader. Très pratique mais que je déconseille pour la production. Sa gestion des timeout est inéxistante et l' utilisation de la méthode onLoadError conduit à des catastrophes.

Sur mes projets j' utilise la classe LibStack de Pixlib. Si vous ne savez toujours pas ce qu'est Pixlib, rendez-vous ici. Attention, dernière fois que je répète !.

UPDATE:

NOM DE LA FONTE ET RISQUE DE CONFUSION.

Attention à utiliser le "vrai" nom de la fonte au moment du format coté Flash.

La fonte Georgia Gras illustre parfaitement ce cas. En effet, bien qu'il s'agisse d'une variante de Georgia, son nom réel est pourtant "Georgia".
Ou trouver cette référence ? Dans le fichier TTF lui-même, après indication de la signature numérique.

Un bemol

Je n'ai pas encore pu cerner la raison exacte, mais il semblerait qu 'un délai soit parfois nécessaire afin d'assurer la disponibilité de la fonte dans la librairie.

Pour OSFlash pizza, l'instantiation de l'application a été retardée avec un setTimeout:

public function Main(target)
{
target.__proto__ = this.__proto__;
target.__constructor__ = Main;
this = target;

XrayLoader.loadConnector("main_xray_v1.3.4.swf", _level1);

setTimeout(this, "init", 500);
}

private function init()
{
var pizza = Application( attachMovie(Application.id, "pizzaService", 1) );
}

Je remercie erixtekila qui m' a indiqué comment simplifier (de moitié!) la configuration xml. En fin de compte si vous lisez son article qui traite le même sujet, on s'aperçoit que les techniques sont bel et bien identiques. A une nuance près, celle exposée ci tient en un seul xml.

Liens d' intérêt sur Libstack
http://www.get-url.net/blog/?47--pixlib-libstack-ou-le-multi-chargement
http://www.rosyflower.net/dotclear/index.php?2005/12/22/17-preloader-pixlib-