C'est l'alliance de deux grandes idées, le framework PixLib de Francis Bourre et le format d'échange de données SWX d'Aral Balkan.

Longue vie à pixSWX

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é !

Un concours est lancé avec remise de prix officiel au prochain Flash In The Can.

A vos IDE !

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.

J'encourage tout ceux qui peuvent le faire à demander cette formation sur mesure, donc adapté à vos problèmatiques. Le niveau est élévé mais Francis sait vous tirer vers le haut et surtout partager sans retenu ses petits trucs comme ses grandes idées. En plus il est sympa !

Autre avantage, j'ai pu avoir des explications en direct sur des points de PixLib dont j'étais passé à côté. Je vais essayer de vous faire partager tout ça dans les prochains jours.

Bref, une seule chose à dire : Merci Francis.