• Collections : harmonisation des Collections et documentation compléte.
• Structures : les classes Point et Rectangle sont supprimées car redondantes avec les classes natives.
• Medias : le paquetage sound va être entièrement refait et un paquetage video mis en place.
• Data (accès serveur) : Le paquetage data laisse sa place au paquetage service avec toute la partie abstraite mise en place, des paquetages concrets vont voir le jour pour remoting et toutes les technologies possibles.
• Locator : Tous les locators implémentent maintenant la même Interface Locator, le FrontController devient aussi un Locator.
• Transitions : Pour les transitions, la notion de onEnterFrame va disparaître au profit de onTick. Mais celà demande un gros boulot + de l'optimisation des Tweens.
• ConfigLoader : Le ConfigLoader est IOC orienté maintenant, merci a Ali_o_kan.
• IOC : Gros refactoring de la partie IOC qui n'est pas finalisée pour l'instant. Avec des Parser configurables et une notion de namespace dans les contextes qui permettra d'inclure une appli lowra en tant que plugin d'une autre appli.
• LoopCommand : La LoopCommand est une classe importante qui permet de ne pas freezer le player lors du parsing de gros XML ou de manipulation de données. Le XMLLoader va d'ailleurs être redesigné.

Ca bouge donc beaucoup et ce n'est qu'un début. LowRA est toujours en Alpha, principalement sur la partie IOC. Vous pouvez jetter un coup d'oeil au SVN, mais il bouge pas mal et ce n'est pas fini

D'autre part, un gros effort va être fait sur la documentation et des outils communautaires vont être mis en place, notamment un aggrégateur des fils RSS des différents blogs LowRA. Tout se passe désormais sur googlecode. Donc je vous conseille d'y venir en masse pour vous inscrire à la mailing liste officielle LowRA et vous tenir au courant

PS : Ali_o_Kan a publié la discussion compléte

Cairngorm

Présentation

Cairngorm est un Framework dédié à Flex et qui propose une implémentation du principe du FrontController.

Il propose aussi une gestion des échanges serveurs à travers plusieurs principes :

Le Business Delegate qui est une classe proxy gérant toute la logique de communication directe avec le serveur (web service, http ou autres). Elle est appelé par les commandes, qui leur passe deux méthodes : onResult, onFault recevant les résultats.

Les Value Object qui sont des objets de retour du serveur Remoting. Ils sont automatiquement mappés par Flex à nos propres classes. Pour cela les classes doivent indiqués le type AMF correspondant.

Le Service Locator qui permet de centraliser l’accès aux différents service (Web Service, http, XML) avec une interface unifiée.

Points forts :

• Framework léger (à peine une vingtaines de classes)
• Soutenu, documenté et géré par Adobe de manière officielle
• Répandu dans la communauté Flex donc assez universel

Points faibles :

• Totallement dépendant du Flex SDK, ne peut donc pas s'utiliser dans des projets Flash ou pur ActionScript
• La mise à jour des vues dans le cadre d'une mise à jour des modèles se fait par data binding, ce qui peut poser des problèmes de lisibilité du code et de debugging. (Ex. Si une propriété du modèle n'existe plus, on n'aura pas de notification d'erreur)

Liens

• http://labs.adobe.com/wiki/index.php/Cairngorm
• http://www.cairngormdocs.org
• http://www.cairngormdocs.org/tools/CairngormDiagramExplorer.swf
• http://www.cairngormdocs.org/docs/cairngorm_2_1/index.html

LowRA

Présentation

LowRA est la version AS3 des Framework PixLib et PixIOC.

Il propose notamment une implémentation du principe du FrontController. Mais aussi beaucoup d’autres choses.

Entre autres :

Un Service Locator qui permet de centraliser l’accès aux différents service du côté serveur.

Un paquetage de Tween.

Des paquetages de Collections et d’Iterator.

Une gestion unifiés des Loading (Graphique, son, XML, etc…) et la possibilité de créé des piles de chargement.

Une possibilité d’avoir des Commandes déclenchés à intervalles réguliers.

Une gestion d’événements typés et un eventBroadcaster propre au Framework.

Les deux autres grosses parties du Framework concernent l’IOC et par extension la possibilité de créé une application par plugin.

Points forts :

• Non basé sur le Flex SDK
• Propose beaucoup plus que simplement une implémantation du MVC+C
• Propose une implémentation d'IOC et une architecture de plug-in toute faite
• Open source et possibilité d'évolution

Points faibles :

• Pas de version stable (pour l'instant)
• Certains éléments non développés à l'heure actuelle
• Documentation manquante

Liens

• SVN : http://lowra.googlecode.com/svn/trunk

• http://osflash.org/projects/lowra
• http://www.geturl.net/lowra/
• http://groups.google.com/group/lowra//a>
• http://www.community.oddlyonward.com/

PureMVC

Présentation

PureMVC propose lui aussi une implémentation du pattenr MVC+C en se reposant aussi sur pas mal d'autres patterns (Proxy, Observer, Facade, Mediator)

Dans PureMVC, View et Model sont deux classes qui ne font que donner des accés a des listes d'instances (de Mediator pour View et de Proxy pour Model) et elles sont elle mêmes gérées par la facade qui est le point central de l'application.

Points forts

• Non basé sur le Flex SDK
• Implémentation rapide sans héritage (on utilise directement les classes du framework)
• Bonne documentation et site actif derrière
• Bonne réputation

Points faibles

• Système événementiel différents des habitudes
• Pas de Notification typées
• Nomenclature des classes différentes donc un peu plus longe à appréhender
• Certains points (Mediator) peuvent nécessiter un redéveloppement (cf mon post précédent)

Liens

• http://www.puremvc.org/

Et pour ne pas rester en reste il y aussi ceux là :

• Vegas
• ARP
• Foundry (Flex)

Au final et pour ne pas éluder la question, je dirais qu'on peut conseiller Cairngorm dans le cadre de projet Flex pas trop gros et passer à PureMVC ou LowRA si vraiment le projet grossit trop. J'ai fait la manipulation sur un mini projet, la transition se fait assez facilement. Au final, le passage en PureMVC est quand même un peu plus long du fait de la nomenclature radicalement différentes des classes. Donc Cairngorm est une bonne introduction aussi pour ceux qui ne sont pas super à l'aise avec le pattern MVC+C. C'est un framerwork qui va à l'essentiel et qui est ultra bien documenté. Par contre dans le cadre d'un projet ActionScript hors Flex je recommande LowRA sans hésiter tant il apporte tout un tas de faciliter (loaders, event typés, request, collections) sans parle de l'IOC et des plugins. Même si PureMVC, n'est pas absolument lié à Flex, il semble logique de l'adatper pour les gros projets Flex. On pourra toujours extraire certaines classes de LowRA pour des besoins particuliers.

Sur ce, bon dev et bon week-end

J'explore actuellement les frameworks proposant une implémentation du principe MVC+C (dit aussi FrontController) .

J'ai découvert PureMVC qui est pas mal dans son genre. ( Et je ne suis pas le seul à le dire

Si vous venez, comme moi, de PixLib / LowRA ou Cairngorm, un peu de traduction s'impose ! Dans PureMVC, les ViewHelper sont des Mediator, les Events des Notifications et les EventBroadcaster des Observer.

C'est le Mediator qui m'intéresse tout particulièrement ici.

Dans PureMVC, chaque Mediator posséde une constante statique publique NAME de type String. Elle détermine son identifiant unique. Mais comme il s'agit d'une constante on doit la définir dans le code, pas de possibilité de la définir au runtime. Afin de référencer les Mediator, la classe View centralise leur accès en appelant sur chaque Mediator référencé, la méthode getMediatorName(). Du coup, il faut dans chaque classe étendant Mediator, copier/coller le code de la méthode getMediatorName(), pour quelle accéde bien à la constante de notre classe et non à celle de la super classe.

 
override public function getMediatorName() : String
{
return NAME;
}
 

Un peu lourd, je trouve et surtout pas très heureux dans le genre.

Lors de l'enregistrement d'un Mediator dans la classe View, cette dernière va aussi demander une liste des Notifications auxquels ce Mediator devra être abonner. Pour cela il passe par la méthode listImplementations qui renvoie un tableau de type de Notification (String). Le callback pour chaque Notification est le même une méthode handleNotifications( notification : INotification). Du coup, il faut faire un switch dans chaque Mediator pour adapter la logique selon le type de Notification reçue. Brrrrr...

Je propose donc une classe KoMediator avec deux solutions qui me semblent un peu plus élégantes :

1- Le nom du Mediator

Pour cela j'utilise une propriété d'instance privée, transmise au constructeur. Ce qui permet d'utiliser une seconde classe qui va simplement lister les noms uniques de nos Mediator en constant publique de classe et notre classe héritant du KoMediator, passera la référence à cette variable :

 
class ExampleMediator extends KoMediator
{
public function ExampleMediator( document : Object = null )
{
super( document, MediatorList.EXAMPLE )
}
} 
 
class MediatorList
{
public static const EXAMPLE : String = "example";
}
 

Ainsi la signature de notre Mediator est la même que celui du Mediator d'origine de PureMVC

2- Gérer les notifications avec une méthode pour chaque et sans switch

Pour cela, j'ai "extrait" la classe HashMap de LowRA et me suis contenté de la rendre indépendante du reste du framework. Le code complet de cette classe est donc bien de Francis Bourre. Je me sert donc d'une instance de Map pour garder la liste de mes notifications en clefs, la valeurs correspondantes étant la méthode qui va recevoir la Notification.

 
class ExampleMediator extends KoMediator {
public function ExampleMediator( document : Object = null )
{
super( document, MediatorList.EXAMPLE )
_mNotificationInterest.put( NotificationList.MODEL_UPDATED, onModelUpdate )
}
private function onModelUpdate( notification : INotification ) : void
{
}
}
 

Ainsi on a une implémentation bien plus simple et proche du EventBroadcasting classique.

Enfin je trouve.

Pour ma part.

Et de mon humble avis...

Et vous ?

Venant de PixLib, je m'étais bien habitué en utilisant les ViewList, en gros une classe de constante public listant les identifiants uniques des vues. Pour prendre la même technique mais dans Cairngorm, il suffit d'overrider la function initialized de notre helper de la façon suivante :

 
override public function initialized(document:Object, id:String):void {
 	super.initialized( document, ViewList.VIEWNAME);
}
 

Où on remplace bien sur VIEWNAME par la constante de l'id unique. Simple, mais efficace. On est ainsi sur que c bien notre helper qui donne son id et non le mxml l'incluant.

Une propriété statique USE_ATTRIBUTE_NAME qui est un Boolean (false par défaut). Il désactive l'utilisation de l'attribut name d'un noeud en tant que nom de propriété de l'objet déserialisé (du coup c'est le nom du noeud qui est utilisé

Une méthode d'instance

 
 forceType( sNodeName : String, sType : String);
 

Elle permet d'indiquer un type pour des noms. Le but étant de pouvoir gérer des types sur des XML sur lesquels on a pas la main.

Une classe et un xml de test sont dans le zip mais en gros voici le principe :

Mon XML

<?xml version="1.0" encoding="UTF-8"?> <root> 	<test1NodeName name="test1AttributeName">Cool</test1NodeName> 	<test2>'item1','item2','item3'</test2> </root>

Si je le charge avec le Deserialize de base voici en gros ce que j'aurais :

 [
Object] test1AttributeName : "cool" // Type String
test2 : "'item1','item2','item3'" // Type String
 

Avec mon déserializer, en forcant le type du noeud test2 sur array :

 
[Object] test1NodeName : "cool" // Type String
test2 : [Array] // Type Array
[0] : "item1"
[1] : "item2"
[2] : "item3"
 

Et voici le bout de code dans la classe Test.as, au passage vous noterez que j'ai mis les types en propriétés statiques pour plus de sécurité...

 
// Méthode classique
var xto : XMLToObject = new XMLToObject( {} );
xto.addEventListener( XMLToObject.onLoadInitEVENT, this, debugObject );
xto.load( "test.xml" );
// Flapflap Style <img src='http://kilooctet.net/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' />
KoXTODeserializer.USE_ATTRIBUTE_NAME = false;
// On utilise plus l'attribut name
var deserializer : KoXTODeserializer = new KoXTODeserializer();
deserializer.forceType("test2", KoXTODeserializer.ARRAY_TYPE);
// ON force le type Array pour le noeud test2
var koXto : XMLToObject = new XMLToObject( {}, deserializer );
koXto.addEventListener( XMLToObject.onLoadInitEVENT, this, debugObject );
koXto.load( "test.xml" );
 

Deux limitations : On force un type pour un nom de noeud donc si on a plusieurs noeud a différents niveaux ayant le même nom ils auront le même type Forcer le type array sur un noeud ayant des enfants n'est pas gérer

J'attends vos retour

On m'a toujours dit que la meilleur utilisation à faire des Design patterns n'était pas de concevoir directement avec, mais que lorqu'un problème de conception se posait, voir si il n'y avait pas déjà un Design Pattern pouvant nous aider à le traiter. Mais comme tout ceux qui lisent pour la première fois Design Patterns Head First ou Essential ActionScript, j'ai voulu tester les design patterns en cherchant a les appliquer directement à ma conception d'application.

Heuresement le temps est parfois un grand allié et il nous apporte un peu de sagesse et d'expérience. J'avais donc garder de côté ma liste de Design pattern avec une vague impression d'imaginer ce à quoi ils pouvaient servir. Et puis ce matin, ping (c'est le bruit de l'illumination). Un simple petit jeu concours à réaliser. Rien de bien complexe. Juste des champs de formulaire à valider. Je me suis dit autant en profiter pour faire une petite classe de validation de formulaire rapide et réutilisable.

J'ai donc commencer une classe utils avec des méthodes statiques qui permettraient de valider différents champs tels que E-mail, N° de téléphone, Code postal etc...

Mais bon ça ne me plaisait pas trop, tout ça était un peu lourd. Et là je me suis souvenu du pattern Strategy qui permet de déléguer un algorithme. Ca semblait la bonne solution à mon problème de conception trop lourde à maintenir.

Voilà donc un exemple de ce que ça donne :

D'abord une interface qui va définir la méthode indiquant si un champ est valide ou non :

 
/**  * @author Benoit MILGRAM  */
interface com.nodule.validator.IValidator {
 	public function isValid( s : String ) : Boolean;
}
 

La méthode isValid reçoit une chaîne et indique si elle est valide ou pas.

Ensuite, on créé différentes stratégies selon ce que l'on veut valider :

Une adresse email :

 
import com.nodule.validator.IValidator;
import com.nodule.utils.StringUtil;
/**  * @author Benoit MILGRAM  */
class com.nodule.validator.EmailValidator implements IValidator {
 	public function EmailValidator() {
 	}
 	public function isValid( s : String ) : Boolean {
 		return (( StringUtil.contains( s, "@") ) && ( StringUtil.contains( s, ".")));
 	}
 }

Un code postal :

 
import com.nodule.validator.IValidator;
/**  * @author Benoit MILGRAM  */
class com.nodule.validator.ZipCodeValidator implements IValidator {
 	private static var ZIPCODE_LENGTH : Number = 5;
 	public function ZipCodeValidator() {
 	}
 	public function isValid( s : String ) : Boolean {
 		return ( ( Number( s ) != NaN ) && ( s.length == ZIPCODE_LENGTH) );
	}
 }
 

Une date :

 
import com.nodule.validator.IValidator;
import com.nodule.utils.NumberUtil;
/**  * @author Benoit MILGRAM  */
class com.nodule.validator.DateValidator implements IValidator {
 	private static var DATE_LENGTH : Number = 10;
 	private static var DATE_RANGE_LIST : Array = [ [1, 31], [1, 12], [1900, 2007] ];
 	private static var DATE_LENGHT_LIST : Array = [ 2, 2, 4 ];
 	public function DateValidator() {
 	}
 	public function isValid(s : String) : Boolean {
 		if( s.length != DATE_LENGTH ) {
 			return false;
 		} else {
 			var dateArray : Array = s.split("/");
 			var dateArray_l:Number = dateArray.length;
			for (var i : Number = 0; i < dateArray_l; i++) {
 				var date : String = dateArray[i];
 				if( Number( date ) != NaN ) {
 					if( date.length == DATE_LENGHT_LIST[i] ) {
 						if( ! NumberUtil.isInRange( Number( date ), DATE_RANGE_LIST[i][0], DATE_RANGE_LIST[i][1] ) ) {
 							return false;
 						}
 					} else {
 						return false;
 					}
 				} else {
 					return false;
 				}
			}
		}
 		return true;
 	}
 }

Pour finir, j'ai créé une classe Validator qui implémente elle même l'interface et qui va recevoir en argument du constructeur la classe ayant la stratégie adéquat :

 
import com.nodule.validator.IValidator;
/**  * @author Benoit MILGRAM  */
class com.nodule.validator.Validator implements IValidator {
 	private var _oValidatorStrategy : IValidator;
 	public function Validator( strategy : IValidator ) {
 		_oValidatorStrategy = strategy;
 	}
 	public function isValid( s : String ) : Boolean {
 		return _oValidatorStrategy.isValid( s );
 	}
 }
 

Ainsi pour valider le contenu d'un champ texte nomé tiEmail et qui ait censé contenir un email :

 
import com.nodule.validator.Validator;
import com.nodule.validator.EmailValidator;
var validateEmail : IValidator = new Validator( new EmailValidator() );
validateEmail.isValid( tiEmail.text);
 

On peut rapidement et facilement maintenir notre code. Chaque classe ayant la responsabilité de valider un type d'information. Et on peut rapidement et facilement ajouter de nouveau type de validation sans que notre classe Validator ait besoin d'être modifié !

Ca promet tout ça !

For now, it was make with Zinc but I hope next release will come using HaXe... If you have some skills on it and a little bit of time be welcome ! Also it use MM Components and I'll try to go to ASWing as soon as possible. My intention is to make a perfect Open Source Flash project... Also to create the Command it use a template you can find in the template folder created by the app at launch time. Change it after launching to change youre command line code. There is just two tags $package$ and $name$ to keep...

!!! WARNING!!!! This is an earlier alpha and I just make some quick test. This application write on your as files so use it with care. I suggest you to make a copy of one of your PixLib's based work for test if. I wait for you feedback at flapflap_at_kilooctet.net

Let's take PEACE

PEACE (Pixlib Event And Command Editor) Alpha version 0.0.1 est disponible !! Son principe en est simple : c'est un petit éditeur qui vous permet dans le cadre d'un framework basé sur le FrontController de PixLib, d'ajouter rapidement une commande de rajouter l'événement correspondant dans la EventList et de les lier dans le Controller. Pour celà vous devez préciser votre dossier source. Automatiquent Peace va rechercher les classes nommées EventList et Controller ainsi qu'un dossier command. Si il ne les trouve pas vous pouvez les préciser (notamment si vous les avez appeller autrement). Ensuite, il va vous lister les événements, les commandes et ceux qui sont liés. Pour l'instant tout ça est brut dans un TextArea. Le but étant un test de pertinence et de couvrir un premier panel de test.

Pour l'instant, l'exécutable est généré par Zinc mais j'espère pouvoir utiliser HaXe pour les prochaines versions. Si vous y connaissez n'hésitez pas à me contacter... J'utilise aussi les composants Flash mais je vais passer sur ASWing dès que possible. Le but étant de faire un projet totalement Open Source Flash. J'oubliais, pour créer les Command, j'utilise un template situté dans le dossier du même nom. Vous pouvez le modifier à votre guise mais uniquement une fois l'application lancée. J'utilise juste deux tags : $package$ et $name$.

!!! ATTENTION !!!! Ceci est une alpha et je n'ai procédé qu'a des tests rapides. Ce programme intervient sur vos fichiers as donc merci de le tester avec précautions. Je vous conseil de copier un de vos projets pour faire le test. J'attends vos retours avec impatience sur flapflap_at_kilooctet.net

Let's take PEACE

Je reviens rapidement sur le pattern MVC, il s’agit simplement de séparer les responsabilités d’une application, d’un composant ou d’une partie quelconque d’une application ayant une partie graphique en trois objets : le Modèle, la Vue et le Contrôleur. Le Modèle est toujours la partie la plus difficile à appréhender alors qu'on comprend facilement que la Vue gère les éléments graphiques et le Contrôleur les actions déclenchées par l'utilisateur. En fait, le Modèle est en charge de toute la logique abstraite et non uniquement de la gestion des données comme je le pensais au départ. Le Modèle est bien plus qu'un simple réceptacle à données, à la limite il en gère peu d'ailleurs, déléguant cette gestion à d'autres classes et allant chercher dans celle-ci les infos nécessaires. La logique abstraite est donc l'unique responsabilité du Modèle.

Pour nous faire comprendre ce principe simple, Francis a utilisé un exemple que je m'empresse de reprendre ici : un simple menu.

Nous partirons par exemple d'un XML (mais ça pourrais être un tableau).

Un objet aura la responsabilité de charger et parser cette XML. Par exemple, et totalement au hasard, on pourra utiliser PixLib pour le charger et le déserializer. Une fois notre XML transformé en un objet, il sera passé au Modèle c'est le début de la logique abstraite.

Dans cet exemple, j'aurais une tendance à faire que le Modèle passe ce tableau à la Vue qui aurait parcouru le tableau pour créer les différents éléments en fonction des données. Mais la responsabilité de parcourir le tableau est attribuée au Modèle et il est absurde de le faire parcourir deux fois par deux objets différents. Donc notre Modèle va parcourir cet objet est va simplement à chaque itération lancer un événement écouter par la Vue et relié a une fonction du type addMenuItem(); par exemple.

Ainsi la logique abstraite est bien séparé de la gestion graphique et pourra inter changer nos Vue. L'idéal étant de créer une Interface pour les Vues qui voudront écouter ce Modèle.

Ca paraît logique ainsi dit mais j'ai eu souvent tendance à laisser de la logique abstraite dans les Vue et on tombe alors dans une problématique de couplage fort. Une partie de la logique abstraite étant dans la Vue, la relation entre la Vue et le Modèle devient plus lourdement dissociable. On perd donc de la souplesse.

Je ne sais pas si tout ça vous a aidé, mais moi ça m'a bien remis les idées en place.

Si vous ne l'aviez pas c'est un must !