Une petit astuce que j'ai découverte sur le site d'Adobe en cherchant à résoudre un problème de sécurité Crossodmain lié à la mise à jour de la sécurité dans le Flash Player 10 :

Dans le fichier mm.cfg ajouté ces deux lignes :
PolicyFileLog=1 # Enables policy file logging
PolicyFileLogAppend=1 # Optional; do not clear log at startup

Et le Flash Player vous créera un fichier policyfiles.txt dans le dossier Application Data/Macromedia/Flash Player/Logs de votre dossier de profil, dans lequel vous aurez tous les détails sur les problématiques de sécurité.

• 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 ?

Pour moi la vocation première d'un Adobe User Group est d'organiser des réunions. Dans ces réunions, un ou plusieurs intervenants présentent un domaine d'expertise particulier et précis, puis la discussion s'engage autout de ce thème. On peut ainsi partager nos expériences, apprendre de nouvelles technique et surtout ne pas rester chacun dans son coin avec nos problèmes et nos solutions.

En France, il ya 4 groupes référencés.. Ce n'est pas pour leur jetter la pierre, mais ils ont chacuns leur vision de la chose, en général ils proposent des forums et mailing lists. Et plus ou moins de chose vraiment "communautaire". Il faut aussi reconnaître qu'il s'agit parfois, pour eux, d'un moyen de promotion. On ne peut pas leur en vouloir, mais à mon avis il manque quand même l'organisation de ces fameux meetings.

Le tout n'est pas de critiquer à tout va, mais surtout d'avancer ! Première étape, j'ai contacté les responsables de ces groupes par ce mail :

Salut à tous, Je m'adresse à vous car vous êtes les quatre personnes référencées comme "User Group Adobe" ici :
http://www.adobe.com/cfusion/usergroups/search_results.cfm?findType=2&country_id=97D6B664-FA16-4DF4-905916C8318473CE autour de la plateforme Flash. Je pense qu'il y a un gros manque en France en terme de réunion de Flasheur / Flexeur.
Nous sommes très bien fourni en forums et mailings list, formations et relativement bien en festivals.
Mais jamais de "User Group Meeting", ce qui est, à priori, la raison d'être d'un User Group. Voir ce qui est fait à Londres  : http://www.lfpug.com/ ou Montréal : http://www.montrealadobeusergroup.com/ ou Belgique : http://www.adobeusergroup.be/ 

Donc, j'étais sur le point de mettre en place un Adobe User Group dont la vocation serait de créer des réunions de présentation et d'échange par des Flasheur / Flexeur français. On a la chance d'avoir une grosse communauté et des gens talentueux qui travaillent sur des projets à résonnance internationales, pourquoi se priver de leur savoir ? 

J'ai quelques idées sur ce qu'on pourrait faire et comment, mais je trouve que lancer une nouvelle initiative, tout seul, n'est pas très productif. Si vous êtes donc réceptif et prêt à entrer dans l'aventure, parlons-en !
Merci à tous,

J'attends les réponses, mais en attendant j'ai voulu faire se billet pour ouvrir la discussion :

Qu'attendez-vous vraiment d'un User Group ? Quelles sont vos idées pour organiser les réunions ? Quels sont les sujets que vous voulez voir aborder ? Quels sont les sujets que vous aimeriez présenter ?

En attendant, de faire un vrai meeting "sérieux", mon collégue Tekool organise un déj sur Paris. Une nouvelle occasion de se rencontrer et d'échanger.

En attendant, peut-être, de vraie réunion de groupe d'utilisateurs.

EDIT::Je rajoute le lien de la AUGG (Adobe User Group de Genève), un exemple à suivre : http://www.augg.ch/spip/

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

Ca promet tout ça !