[VEGAS] IoC proposal : connect signals in object definitions

[eKameleon]

Hello :)

je suis en train de réfléchir pour utiliser les Signals dans les
définitions d'objet pour simplifier la connection avec les fonctions
ou receicers d'une application. Un peu comme pour l'attribut listeners
actuel je pense implémenter un nouvel attribut.

Pour le moment j'ai ouvert une issue sur google code à ce sujet :
http://code.google.com/p/vegas/issues/detail?id=85

Avec en gros pour ceux qui ont pas envie de cliquer sur le lien une
signature de l'attribut receivers :

{
id : "my_receiver" ,
type : "system.signals.Receiver" ,
singleton : true ,
lazyInit : true ,
receivers :
[
signal : "my_signal"
]
}

ou

{
id : "my_receiver" ,
type : "system.signals.Receiver" ,
singleton : true ,
lazyInit : true ,
receivers :
[
signal : "my_object.signaler" , slot : "mySlot" }
]
}

N'hésitez pas à me donner vos idées là dessus :)

EKA+ :)


--
Subscription settings: http://groups.google.com/group/vegasos/subscribe?hl=fr

[eKameleon]

Hello :)

Ok tout semble ok maintenant sur les dernières version de VEGAS, avec
en prime une mise à jour de la documentation sur les définitions
d'objet (chapitre B) :

http://sites.google.com/site/ekameleon/Home/opensource/vegas-opensource-project/vegas-tutorials/ioc---object-definitions

Voir chapitre B-2.6 L'attribut "receivers"

EKA+ :)

[Flchakir]

Hello !
je tien a te remercie pou cette nouvelle mise a jour , d'ailleurs
que je trouve génial de pourvoir implémenté rapidement ce nouveau
attribue receviers , pas juste pour lui meme , mais parceque ça preuve
vraiment que IoC su vegas est solide et trop evolutif , en dotant
d'une fluidité et souplesse qui rendent le developpement un plateau de
kike , meme pour des concepts vraiment nouveaux dans leur
implémentations , je parle de l'implémentation par ceque le concept
existe deja en C# qui etait la base pour la 1e implémenation as3-
signals ,mais cella est bcq mieux et surtout adapté pou as3 ,

D'autre coté j'avais pas mal de questions la dedans par rapport au 1er
post , mais tout est bien clair avec la bonne documentation et
l'exemple ,donc encore merci Eka pour tes efforts,

mais encore j'ai un petit souci en pensant a remplancer le model
Evementiel standard pour les échanges des évènements entre les
différents objects , sauf pour les évènements I/O . avec les model
signaux , faudra que ta classe implémente Receiver , et qu'elle soit
de type Signal pour diffuser , or que pour le modele standard tout
les Object type DisplayObject dipatchent et acceptent un abonnement a
l'écouteur via addEventListener , ce qui donne une souplesse dans
l'ajout et la suppression de listeners pour un évènement dans IoC , si
on utilise des objets affichables ,et si ce qu'on utilise souvent ,
donc je sais pas si tu as mécanisme plus soft pour aller plus loin
avec ca .

chakir

[eKameleon]

Hello :)

En gros tu veux des signals dans ma classe RemotingService mais aussi
dans mes classes pour gérer les chargement eden, xml, etc ? :)

En général faut pas trop se prendre la tête car dans l'ioc pour gérer
tout cela on peut utiliser les outils du package system.process et les
outils des packages vegas.net et vegas.net.remoting

Maintenant il est clair que je pourrai développer des versions de ces
outils basés sur les Signals dans quelques temps, faut pas hésiter à
m'ouvrir des tickets dans la "issue list" du projet :

http://code.google.com/p/vegas/issues/list

Avec ces 3 packages on peut facilement gérer tout le reste ;) Un bon
exemple à ce sujet dans AST'r avec l'exemple eGallery advanced :

http://code.google.com/p/astr/source/browse/#svn/trunk/AS3/trunk/examples/egallery/advanced/trunk

Cet exemple montre comment utiliser remoting avec AMFPHP avec les
classes AS3 RemotingService + RemotingServiceListener (classe qu'il
faut utiliser avec de l'héritage) et une petite dose rapide d'IoC +
MVC based VEGAS pour faciliter le remplissage des données dans le
modèle de l'application et la gestion de celles ci.

EKA+ :)

[qatab chakir]

salut Eka ,

j'ai bien regardé , c'etait bien clair , comment faire une utilisation correcte et complète avec l'IoC , ainsi l 'utilisation du FrontController et le MVC ,

Néanmoins j'ai des interrogations a propos de la souplesse de IoC via un fichier externe de config ,sachant que IoC permet que chaque application / module dans la couche de présentation a son propre fichier de configuration. on utilise IoC comme conteneur léger d'injecter de configuration des classes avec des données

De cette manière, nous pouvons changer d'application (remplacement du module, ajouter des paramètres, en plus des changements, etc désactiver deep linking) sans avoir à recompiler l'application. mais réellement on se confronte a un problème relatif a la nature du Flash de faite qu'il est coté client et donc nécessite l'exportation de la définition des classes dans le swf  pour que le flash player puisse l'interpréter , ce-qui limite en quelque sorte  la souplesse de loC via un context externe , donc  faut que je prévoie à l'avance toutes les classes que je vais utiliser et forcer le compilateur  à les exporter dans le SWF , on tapant  toutes les classes sur la Main de l'application ou une autre classe qui doit être compilée aussi , qui ne sont pas  utilisées immédiatement et en lisant le code on sait même pas pourquoi elles sont la ou quand est ce qu'elles seront utilisées , sauf si on parcours les fichiers de config

Donc pour tout remplacement de module , changement dans certaines classes , utilisation d'une nouvelle classe ...., on est obligé de recompiler l'application entièrement .

Moi j'avais pensé rapidement à une petite solution qui peut me résoudre ce prb ( forcer le linkage en dure et re-compiler toute l'application a chaque fois ) . je la posterai après l'avoir testé , mais j'aimerai bien avoir ton avis sur tous ce que je viens de dire si tu vois bien ma problématique .
NB:( sur java par exemple y a pas ce problème , parce qu'il suffit juste d'avoir Ta classe en .class compilé , pour qu'elle sera reconnu dans IoC  )

chakir

[eKameleon]

Hello :)

Si tu prends par exemple la démo de eGallery advanced dans AST'r tu
peux trouver à l'intérieur un module avec GAForFlash (Google Analytics
For Flash). J'ai compilé une seule fois la library de GAForFlash et je
charge en assembly le module dans le moteur de ressource externe du
chargeur IoC. A partir de là je peux créer une définition d'objet pour
gérer le tracker sans avoir à recompiler quoi que ce soit.

Chargement et initialisation du module ligne 6 et 7 :
http://code.google.com/p/astr/source/browse/trunk/AS3/trunk/examples/egallery/advanced/trunk/deploy/context/application.eden

Mise en place de la définition d'objet pour contrôler le tracker :
http://code.google.com/p/astr/source/browse/trunk/AS3/trunk/examples/egallery/advanced/trunk/deploy/context/net/ga.eden

Du coup il est tout à fait possible d'avoir un module (swf) contenant
un ensemble de symboles, classes, etc...

Dans l'application principale ensuite pour éviter de dupliquer les
appels pour les classes on peut travailler en dynamique (type *) ou
avec des interfaces pour s'assurer de passer les bons objets par la
suite mais en évitant d'alourdir le module principal.

Sinon pour aller plus loin il est possible d'utiliser les RSL et donc
il faut maitriser la compilation avec le compiler du flex SDK. Pour
cela en utilisant quelques techniques il est possible de créer un ou
des swf "remote" en ligne qui contient les classes importantes (celles
de VEGAS, celles du projet mais qui ne changent pas, etc) et du coup
de charger dans le swf principal ces modules et d'exclure dans les
autres swf chargés au fur et à mesure dans l'application en assembly
mais sans que ces swf dupliquent à chaque fois les classes.

Il faut donc bien apprendre à utiliser le compiler en ligne de
commande du Flex SDK et bien lire tout ce qui concerne les RSL + bien
maitriser la notion de ApplicationDomain.

Pour finir faut pas oublier que en AS on peut générer des swf mais
aussi des swc (j'en fourni dans le répertoire trunk/libs de VEGAS par
exemple) et que ces swf peuvent marcher comme pour les .class etc ;)

EKA+ :)

On 3 mai, 16:51, qatab chakir <javacha...@gmail.com> wrote:
> salut Eka ,
>
> j'ai bien regardé , c'etait bien clair , comment faire une utilisation
> correcte et complète avec l'IoC , ainsi l 'utilisation du FrontController et
> le MVC ,
>
> Néanmoins j'ai des interrogations a propos de la souplesse de IoC via un
> fichier externe de config ,sachant que IoC permet que chaque application /
> module dans la couche de présentation a son propre fichier de configuration.
> on utilise IoC comme conteneur léger d'injecter de configuration des classes
> avec des données
>
> De cette manière, nous pouvons changer d'application (remplacement du module,
> ajouter des paramètres, en plus des changements, etc désactiver deep
> linking) sans avoir à recompiler l'application. mais réellement on se
> confronte a un problème relatif a la nature du Flash de faite qu'il est coté
> client et donc nécessite l'exportation de la définition des classes dans le
> swf  pour que le flash player puisse l'interpréter , ce-qui limite en
> quelque sorte  la souplesse de loC via un context externe , donc  faut que

> je prévoie à l'avance toutes les classes que je vais utiliser et *forcer le
> compilateur  à les exporter dans le SWF* , on tapant  toutes les classes sur

> la Main de l'application ou une autre classe qui doit être compilée aussi ,
> qui ne sont pas  utilisées immédiatement et en lisant le code on sait même
> pas pourquoi elles sont la ou quand est ce qu'elles seront utilisées , sauf
> si on parcours les fichiers de config
>
> Donc pour tout remplacement de module , changement dans certaines
> classes , utilisation

> d'une nouvelle classe ...., on est obligé de* recompiler l'application
> entièrement* .

>
> Moi j'avais pensé rapidement à une petite solution qui peut me résoudre ce

> prb ( *forcer le linkage en dure et re-compiler toute l'application a chaque
> fois* ) . je la posterai après l'avoir testé , mais j'aimerai bien avoir ton

[qatab chakir]

Hello ,

C'était exactement mon idée d'utiliser le moteur de chargement des ressource externe et faire passer a chaque fois selon le besoin les swf qui contient les définition des classes comme ça je sera pas amener a re-compiler toute l'application ,
Mais c'est vrai que il y a un petit souci de duplication de définition ,donc faut gérer ça en utilisant ApplicationDomain , parceque je me suis rendu compte que si SWF1 contient la definition de A et SWF2 contient aussi une définition de A , et SWF2 charge SWF1 ,la définition de A sur SWF2 écrase celle de A sur SWF1

Pour la notion des SWC c'est une lib de classe et éléments flash , mais est cequ'elle est exporté avec toutes les classes qui contient pour qu'elles seront accessible pour le flash player a l'exécution ?

merci bcq
chakas

[ekameleon]

Hello :)

Quand tu utilises un swc tu compiles uniquement les classes dont tu as besoin, comme pour des classes classiques :)

EKA+ :)