Par contre, j’ai ce qui est appelé ici des « Dépendances » !! je ne connaissais pas ce principe d’ « injection » que je n’ai aps encore bien comprise d’ailleurs..

Mais bon, toutes mes dépendances sont dans MainApplication.as, mon point d’entrée et est unique pour chaque application. Perso, ça ne me pose aucun soucis et je ne vois pas trop pourquoi ce ne serait pas bien.. Mais bon, comme je doute toujours et que je remets en question sans cesse ma structure, je vais encore y réfléchir.. surtout que mes dépendances sont « static » afin que n’importe quel controler puisse éventuellement accéder à un autre controler via Main.xxx . pour en appeler une méthode et éviter les surplus d’Events.. Technique Barbare??

Là, je fais de la composition sur mon skin.. mais je me demande si je n’aurais aps un interêt à systématiquement étendre mes Clips de Skin pour faire mes controlers.. C’est la question du moment.. Tu as un avis?

Merci et encore bravo pour ton blog!
Alain.

C’est tjrs très discutable le choix entre héritage et composition.. surtout pour une question de structure et pour ne pas tomber dans du code spaghetti.. Perso, j’utilise les deux.. selon les avantages dans un cas ou dans l’autre.. le système évènementiel est incontournable pour l’interface (boutons, etc..). Par contre, on l’utilise également entre classes, afin de garder une structure propre, où chaque classe à ses tâches bien définie.. et ça peut même demander de passer des objets en param. Alors, qu’une classe peut très bien invoquer une méthode d’une autre classe en guise d’Event.. mais là, on croise pas mal de lien inter classes et on tombe dans une structure non structurée et difficile à relire.. Je suis partisan d’un chef d’orchestre qui met en scène tous les musiciens.. les musicien ne décident pas par eux même, sauf si le chef à délégué expressément..

Signals est entre les deux! Il serait en effet judicieux d’y penser pour certains cas..

Code Vue MXML

Merci pour ce tuto très intéressant, je l’ai pour ma part adapté à ma façon de développer en utilisant pour les descripteurs de vue du MXML complet, ainsi qu’en déplaçant les eventListener dans le mediator (cela fait gagner un peu de code).
Le code de vue n’a aucune dépendance avec le reste de l’application, et c’est dommage que ce soit la vue « DiaporamaControls » qui créer le « DiaporamaEvent » plutôt que le médiator qui lui est associé.

DiaporamaControl.mxml

DiaporamaControlMediator.as

public class DiaporamaControlMediator extends Mediator
{
[Inject]
public var controls : DiaporamaControl;

protected function onPrevious(event:MouseEvent):void
{
dispatch( new DiaporamaEvent(DiaporamaEvent.PREVIOUS) );
}
}


Un bon compromis entre les deux écritures serait de mettre un évèneent clic générique dclic

Au départ ça fonctionnait bien directement dans le testeur flash depuis adobe flash mais impossible de le faire fonctionner depuis une page web une fois le swf publié. Il faut donc mettre son swf sur son serveur web et qu’il appelle le port 843 sur la machine serveur. Le serveur doit donc écouter le port 843 pour envoyer le fichier policy pour que le socket puisse se faire depuis le client sur le serveur web. Le serveur nodejs doit aussi écouter le port 8888 (port utilisé dans le tuto) pour que la communication se fasse, cela, seulement si le socket a été accepté (port 843 utilisé par défaut).

Pour chargez le fichier policy, il faut insérer dans votre code flash:


// chargement du fichier de policy, dans un premier temps laissez les * pour acceptez n'importe quel port et domaine
Security.allowInsecureDomain("*");
Security.allowDomain("*");
// Insérez l'adresse de votre serveur node js qui écoute le port 843
Security.loadPolicyFile("http://xxx.xxx.xxx.xxx:843/policy.xml");
// Pour charger le fichier, il faut ajouter ces deux lignes:
var context:LoaderContext = new LoaderContext();
context.checkPolicyFile = true;


Si votre serveur n’envoie pas le fichier policy, vous aurez droit à une erreur #2010.