blog.geturl.net - lowRA

[lowRA] - ConfigLoader, des envies ?

ali_o_kan — Sun, 13 Jan 2008 19:26:00 +0100

Pour ceux qui étaient présent au "meeting" sur lowRA, vous avez peut-être noté que je travail sur la mise en place d'une solution de Config dans lowRA.

Pour le moment, j'ai suis partit sur un merge entre le Config de pixLib et la logique de AbstractView et ViewLocator de lowRA.

Ce qui permet de définir un owner pour les fichiers de configurations.

Par la suite je souhaiterai ajouter des balises dans le parser du package IOC pour pouvoir dans un premier temps charger les fichiers de config (équivalent à la balise dll). Et dans un second temps pouvoir lier le fichier de config au(x) bon plugin(s).

Ca c'est ma vision des choses aujourd'hui, comme je ne serai pas tout seul à utilise lowRA et que plusieurs têtes valent toujours mieux qu'une. :p

Je vous propose de me faire part de vos envies.

++ Laurent

PS. Pour ceux que ça intéresse, je peux vous passer le premier jet du pack de config.

[lowRA] - Owner, la notion de plugin.

ali_o_kan — Sun, 13 Jan 2008 19:01:00 +0100

Bonjour

Je pense que je n'ai plus besoin de convaincre qui que ce soit sur l'intérêt d'utiliser une structure MVC dans le développement d'une application.

PixLib permet de mettre en place une structure MVC + FrontController de manière global. C'est vraiment puissant, mais cette solution à ses limites. Prenons le cas où l'on charge plusieurs application "pixLib" dans un même site, on se retrouve avec des conflits entre les différentes classes global, le même type de souci que l'on a quand on utilise le ciblage via le _root + des loadMovie(). Pour contourner ce problème chacun a mis en place sa propre solution.

Avec lowRA se souci a disparu!

Owner, une histoire de channel

Si vous avez utilisez les channels dans pixLib vous pouvez directement passer au point suivant.

Dans pixLib on a vu apparaître la logique de Channel dans la classe Logger. L'idée du channel était d'émettre les messages de log sur différentes fréquences, et de pouvoir s'abonner sur une, plusieurs ou toutes les fréquences.

[actionscript]
var filtreChannel : LogChannel = new LogChannel("FILTRE");
Logger.getInstance().addLogListener( LuminicTracer.getInstance(), filtreChannel);
Logger.LOG("pif", LogLevel.INFO, filtreChannel);
Logger.LOG("paf", LogLevel.INFO);

Avec cette exemple, on ne recevra que le message "pif" et non "paf" car le loggueur est uniquement abonné aux messages qui sont émis sur le channel LogChannel("FILTRE").

Un plugin == un owner == un channel

Dans lowRA, on a maintenant la possibilité de définir un channel, appelé owner, pour chaque structure MVC.

ce qui donne :

[actionscript]
var monModel : Model = new Model(owner, name); // extends AbstractModel
ModelLocator.getInstance(owner).getModel(name); // récupère l'instance de monModel
var maVue : View = new View(owner, name); // extends AbstractView
ViewLocator.getInstance(owner).getView(name); // récupère l'instance de maVue

Plus de souci de scoop lors que l'on charge plusieurs structures MVC+FrontController global, car chaque plugin a son propre owner (channel).

La suite au prochaine épisode.

[lowRA] - Un petit lifting sur le MVC+FC

ali_o_kan — Sat, 12 Jan 2008 18:42:00 +0100

La première chose qui risque de troubler les utilisateurs de pixLib quand ils débarquent dans lowRA, c'est la disparition du MovieClipHelper.

Pas de panique, c'est un mal pour un bien.

Voici en deux mots comment mettre en place une simple structure MVC dans lowRA.

Commençons tout d'abord par un peu de nomenclature.

Pour rappel, une classe dit Abstraite (Abstract) ne peut être utilisé telle quelle, il faut d'abord l'étendre.

Voyons le cas de l'AbstractModel

Pour utiliser la classe AbstractModel nous devons l'étendre.

[actionscript]
public class DrawingModel 
	extends AbstractModel 
{

	public function DrawingModel(owner : Plugin = null, name : String = null)
	{
		super(owner, name);
		Debug.INFO(this + " is CREATE !!!");
	}

Dans un premier temps nous n'allons pas tenir compte de l'argument owner (~~je le présenterait dans le billet suivant~~, [lowRA] - Owner, la notion de plugin ). Ce qu'il faut retenir c'est que chaque modèle reçoit un nom, il s'agit d'un identifiant (unique!) qui permettra de récupèrer l'instance de la classe de n'importe quel endroit de l'application grâce à la classe ModelLocator.

ModelLocator

ModelLocator est un singleton (je ne veux aucun commentaire des puristes :p ), ce qui veut dire qu'il ne peut exister qu'une seule instance de la classe. Cette classe stock en elle l'ensemble des Modèle de l'application, et donc permet de récupérer de façon global n'importe quelle instance d'AbstractModel instancié.

[actionscript]
ModelLocator.getInstance().getModel("nom_de_mon_model");

Pour les vues c'est la même logique avec AbstractView et ViewLocator. Et pour les commandes c'est presque parreil, la seul différence réside dans le fait que c'est le FrontControlleur qui fait office de locator et que l'identifiant est le nom d'un événement.

[actionscript]
monController.pushCommandClass("monEvenement", MaCommandExecute);

Rien de bien nouveau avec pixLib si ce n'est le pushCommandClass. Maintenant nous pouvons choisir d'exécuter à chaque évènement la même instance de la commande ou dans instancier une nouvelle (plus proche du pattern originel).

[actionscript] 
public function pushCommandClass( eventName : String, commandClass : Class ) : void
public function pushCommandInstance( eventName : String, command : Command ) : void

Voilà, avec ces six classes nous avons de quoi déployer une structure MVC + FrontController en AS3.

En bonus, je me suis amusé à porter un petit projet MVC pixLib vers lowRA.

Les sources AS2 (pixLib).
Les sources AS3 (lowRA) - la build utilise iFac pour compiler.

Pour ceux qui veulent savoir un peut plus sur le MVC+FC dans pixLib :

[lowRA] - Un point de la situation

ali_o_kan — Fri, 11 Jan 2008 12:34:00 +0100

Un premier point vient d'être fait sur l'avancement de lowRA.

Benoît vient de mettre en ligne un résumé en français de la discussion.
LowRA est en train de passer à la prochaine étape.

Pour la version complète en VO : lowra_meeting_070111.html

Tout ce que l'on peut dire c'est que Francis et Cédric mettent les bouchés double depuis une semaine et que l'avenir de lowRA s'annonce rayonnant.

cheers,
Laurent

[MAJ] - Francis en parle aussi : LowRA meeting online

[airLogger] - adieu LuminicTracer, bonjour airTracer

ali_o_kan — Sat, 22 Dec 2007 15:34:00 +0100

Salut

Depuis une petite semaine maintenant j'utilise la nouvelle mouture de AirLogger. Créé par Cédric Néhémie, AirLogger est à ce jour ce que j'ai vu de mieux en logger externe pour Flash.

Ces points fort

Suivi de plusieurs swf, chacun ayant son propre onglet.
Sortie des logs formaté html.
Stockage des logs dans une pile (buffer), si AirLogger est pas lancé au départ.
Copier-coller, moteur de recherche, affichage avancé (couleurs, mail, url,…), …

Une fois en mains, je n'ai pas pu m'empècher à me lancer dans un portage pour pixLib (AS2). Après quelques heures de prise de tête, à deux doigts de lacher le morceau j'ai prit contact avec Cédric qui a terminé le portage.

Donc une première version, non stable, pour l'AS2 est disponnible, hormis un souci sur les MovieClip (return null dans airLogger) elle semble fonctionnelle. Elle s'utilise comme la classe LuminicTracer (cf. [pixLib] - Comment logguer?) :

[actionscript]
Logger.getInstance().addLogListener(LuminicTracer.getInstance());
Logger.getInstance().addLogListener(AirTracer.getInstance());

com.bourre.utils.AirTracer.zip

J'en profite pour signaler que AirLogger est basé sur lowRA (pixLib to AS3). Un bon exemple pour se faire une idée de son utilisation.

info +

Allez, hop, à la douche avant le champagne,
Bonne soirée