Petite question sur ta class ObjectArgument

[NikOS]

J'ai vu que quand tu créé les arguments avec la méthode create , par
défaut c'est la Policy VALUE.

if ( ref != null && ref.length > 0 )
{
args.push( new ObjectArgument( ref ,
ObjectAttribute.REFERENCE , evaluators ) ) ; // ref argument
}
else if ( conf != null && conf.length > 0 )
{
args.push( new ObjectArgument( conf ,
ObjectAttribute.CONFIG , evaluators ) ) ; // config argument
}
else if ( i18n != null && i18n.length > 0 )
{
args.push( new ObjectArgument( i18n ,
ObjectAttribute.LOCALE , evaluators ) ) ; // locale
argument
}
else
{
args.push( new ObjectArgument( value ,
ObjectAttribute.VALUE , evaluators ) ) ; // value argument
}

Mais question est si jamais on se trompe dans l'IOC, par exemple si on
écrit 'local' au lieu de 'locale', la méthode prendra-t-elle la valeur
comme une Policy de type VALUE ?
Afin de débuguer l'IOC, ce serait peut-être bien de lancer une
exception si on se plante à ce niveau?

NikOS
;)

[ekameleon]

Hello :)

Si tu te trompes il ignorera ton attribut non compatible avec le DOM des définitions d'objets. Tout simplement car sinon cela risque d'être chaud de faire du debug. Au pire je pourrais ajouter un niveau de "verbose" réglable selon l'intensité des logs que l'on souhaite mettre en place.. mais cela risque d'alourdir l'IoC... surtout que tu sais que nous allons nous mettre sur une solution AIR qui permettra de plus penser à ce genre de choses ;)

Si je fais planter l'IoC ... cela risque encore d'être embêtant si tu modifies un fichier eden de config de la fabrique et que tu fais une boulette et que j'ai pas de log propre pour renvoyer l'erreur :) Donc je pense pas que cela soit une bonne solution.

Donc pour le moment faut être attentif quand on créé nos fichiers de configurations externes et ensuite bah on pourra se fier à l'application de build simplifié pour créer nos définitions d'objets sans se soucier des problèmes d'attributs, etc..

eKA+ :)