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

Le sujet du jour :
Faire que Flex Builder 3 (ça doit fonctionner aussi pour le 2) nous affiche un beau menu listant les évènements émis par une classe (z'avez vu comment j'ai résisté à l'idée de mettre un anglicisme du style "dispatchés" ou "broadcastés", pourtant c'est dur).
Il le fait déjà pour les évènements par défaut, mais il peut aussi afficher les votre.
Il faut pour cela respecter un certain nombre de conditions :

1- Le type de l'évènement doit être une constante de sa propre classe.


package test
{
import flash.events.Event;

}
}


Ceci nous oblige a avoir nos types stockés dans chaque classe. Pas possible de faire une liste d'enum pour plusieurs types d'évènements différents. Enfin, celà reste possible mais nous obligerait à multiplier les classes :


package test
{
import flash.events.Event;

}
}


Un peu redondant...

2- La classe émettrice de l'événement doit contenir un metadata Event.


package test
{
import flash.utils.setTimeout;

}
}


[Event(name="testEvent",type="test.TestEvent")] est le metadata Event complet.
La chaine "testEvent" correspond bien a une constante de la classe TestEvent. Ainsi Flex Builder saura retrouver le nom de cette constante pour vous l'afficher :

Et voilà, le tour est joué

Peut-être avez vous noter qqs soucis dans l'accés à KiloOctet ces derniers temps.

Tout est rentré dans l'ordre avec le nouveau blog, maintenant propulsé par WordPress...

Encore qqs ajustements et tout devrait être d'équerre

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

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.

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