New IoC version - Question about FlashVars !

[eKameleon]

Hello :)

Je débute une nouvelle version du moteur IoC de VEGAS avec un
déplacement d'une bonne partie du code actuel dans le nouveau package
system.ioc et une simplification du package de nombreuses classes
(exemple : vegas.ioc.factory.ObjectFactory devient
system.ioc.ObjectFactory) et avec la disparition progressive de
certaines implémentations inutiles comme la classe ECMAObjectFactory
avec ses méthodes getInstance( name:String) statiques bien inutiles si
on cherche un peu à utiliser une ou plusieurs fabrique il est
préférable par exemple de créer un singleton de package simple... bref
on en reparlera d'ici peu ;)

En attendant une question métaphysique se pose ce matin avec la
propriété "flashVars" que j'ai bien envie de renommé car en fait je
compte bien porter progressivement la logique IoC vers une meilleure
standardisation et aussi dans différentes version AS, JS, etc. Du coup
le terme de "flashVars" ne me convient plus ! Car du coup l'ioc ne
correspond pas à une fonctionnalité de flash mais plus généraliste.

Je vous propose donc dans la prochaine version de créer une propriété
identique que la propriété flashVars actuelle mais avec un autre nom,
exemple :

- arguments
- parameters (identique au niveau du nom à la propriété dans
loaderInfo.parameters de l'AS3)
- variables

Du coup forcément je compte reprendre la classe actuelle
vegas.net.FlashVars et en créer une autre (namespace non défini
encore) avec un nom proche de la propriété utilisée dans la fabrique
ioc nouvelle version :)

Exemple : Arguments, Parameters ou Variables

Pour le moment j'aime bien le nom de Parameters ! et du coup dans
l'ioc la référence magique #flashvars deviendrait #params ou
#parameters (plus long :()

Qu'en pensez vous ???

EKA+ :)

[zwetan]

bonne nouvelles tout ca :)

j'irais pour Parameters ou Arguments

et en fait arguments pourrait etre plus pratique car tu pourrais
le reduire a #args


on peut voir les choses comme ca

dans un outil en ligne de commande argv et argc
sont les parametres qui permmettent de configurer l'application

dans un context "web", les flashvars sont les parametres
qui permettent de configurer l'application

le context est différent mais l'utilisation est tres similaire
et en soit "parameters" et "arguments" sont synonymes et
interchangeable

par contre LE truc a prendre en compte c'est que en fonction du
contexte, les arguments peuvent avoir des regles differentes

dans le contexte web la regle serait que les arguments sont déclarés
comme une query string et donc URLencodé
ex: ?a=hello+world&b=123

dans le contexte ligne de commande ce serait que les arguments sont
séparés par un espace
ex: -a="hello world" -b:123

juste pour dire que si tu renommes ca en "parameter" ce serait bien
aussi d'avoir une class ou autre pour "ParameterRules", comme ca le
concept IoC pourrait marcher sur le web mais aussi avec AIR ou
autre :)

zwetan

[ekameleon]

Hello :)

oui voilà l'objectif est de faire marcher tout cela sur tous les supports (ligne de commande dans une application Tamarin, AIR, etc.)

J'ai tout de même fait ma petite recherche ce matin est au niveau code on peut noter une petite distinction entre arguments et parameters :)

* argument refers to "formal parameter"
* parameter refers to "actual parameter"

En gros une différence entres la définition d'une fonction avec ses paramètres et lorsque l'on appelle une fonction on aurait donc les arguments que l'on passe dans la fonction.

Mais bon cela fait pas trop avancé le problème ;)

Donc j'hésite encore entre une classe Parameter ou Argument ... reste qu'en ActionScript et ECMAScript le terme arguments et réservé même si franchement en utilisant une classe Argument et une propriété args ou argument peut passer sans soucis.

Je vais réfléchir encore un peu et voir si d'autres vont prendre le temps de se lancer dans cette discussion ;) mais un changement s'impose ! ;)

EKA+ :)

[goabonga]

Salut Eka, 
je sais pas trop quoi dire mais en Cpp à mon habitude j'utilise int
argc et argv[] dans ma function main pour recuperer les arguments
passé en ligne de commande.
http://msdn.microsoft.com/en-us/library/a1y7w461.aspx

Comme le dit Zwetan, faut peut être garder une porte ouverte pour les
contexte applicatif, Air , Tamarin ...

Maintenant en AS, peut être que "#params" peut être plus approprié
pour un contexte web puisque comme tu le dis dans le premier poste
-> LoaderInfo(this.root.loaderInfo).parameters

Bonne continuation.
@+

[qatab chakir]

Hello ,

J'opte plus pour parameters , par ce que :

1-souvent on utilise le terme arguments  pour les fonctions , et les méthodes que ça soit pour AS ( ) , Java ( main(args[] String),ou autre langage et parametters ,pour tout paramètre qu'on passe a une application ou un Objet haut ou Plugin
2- parameters c'est le nom la propriété de loaderInfo, utilisé dans l'AS3  ,qui  designe les paramètres flashVars
3- parameters c'est le nom utilisé par des bibliothèque JS d'intégration du swf  .

donc je vois que vaut mieux  opter pour parameters pour qu'on se perte  pas , et on reste sur un standard

CHAKAS

[eKameleon]

Hello :)

Je penche pas mal aussi sur le "parameters" avec le "#params" car
c'est pas mal de se dire que l'on paramètre notre application :)

Je vais encore réfléchir un petit peu (pas pressé) mais je reste
proche de cette idée pour le refactoring final ;)

Merci pour vos participations :)

EKA+ :)

On 29 sep, 14:36, qatab chakir <javacha...@gmail.com> wrote:
> Hello ,
>

> J'opte plus pour *parameters* , par ce que :

>
> 1-souvent on utilise le terme arguments  pour les fonctions , et les
> méthodes que ça soit pour AS ( ) , Java ( main(args[] String),ou autre

> langage et *parametters* ,pour tout paramètre qu'on passe a une application

> ou un Objet haut ou Plugin

> 2- *parameters* c'est le nom la propriété de loaderInfo, utilisé dans l'AS3

> ,qui  designe les paramètres flashVars

> 3- *parameters *c'est le nom utilisé par des bibliothèque JS d'intégration
> du swf  .
>
> donc je vois que vaut mieux  opter pour *parameters* pour qu'on se perte

[Faya]

j'arrive un peu tard, voir après la bataille mais je suis
aussi pour le parameters...
plus parlant, plus utilisé, plus "classique" et plus proche de pas mal d'autres langages...
même si avec tout ce qu'il reste à faire autour, c'est plus de l'ordre du détails actuellement... ;-)

Farfayus