RE : RE : [sdx-developers] Changements récents

[Rasik Pandey]

Salut,

> >Par contre, j'ai vu les récents commits : ça devient de plus
> en plus
> >robuste :-)
> 
> Et ça s'améliore :-)

:)

> 
> J'aime bien par exemple le
> FrameworkImpl.getPopulatedProperties() qui
> correspond à ce que j'avais proposé sur [sdx-users] (même si ça
> pourrait
> s'appeler plus simplement populateProperties).
> 
> Note : cette approche par propriétés m'a toujours un peu
> surpris dans SDX 2
> (à cause du transtypage). Personnellement, je suis plutôt de
> l'école :
> 
> setXXXProperty(StrongType property) / StrongType
> getXXXProperty(). Peu
> importe...

Quand j'aurai du temps je vais remplacer Properties.java et le Hashtable avec 
le DefaultContext pour respecter l'interface Contextualizable de Avalon...

>Ca le serait peut-être encore mieux en éclatant les
> sous-classes
> dans les packages ad hoc ? Pas grave.

Que veux-tu dire ici? 

Comme fr.gouv.culture.sdx.application.Properties?

Ou fr.gouv.culture.sdx.application.Application.Properties?

J'aime bien que ça soit centralisé dans une seule interface car on ne sera pas 
obligé d'importer fr.gouv.culture.sdx.application.XXXXX dans 
fr.gouv.culture.sdx.documentbase.* et donc le IoC sera plus facile à verifier.

> Autre chose : déporter les constantes de la même façon ?
> Celles-ci par
> exemple :
> 
> /* String representation for our default pipeline parameter. */
>     protected final String DOC_URL = "docUrl";
>     /* String representation for our pipeline parameter. */
>     protected final String SDX_USER = "sdxUser";
>     /* String representation for our pipeline parameter. */
>     protected final String SDX_DATE = "sdxDate";
>     /* String representation for our pipeline parameter. */
>     protected final String SDX_ISO8601_DATE = "sdxISO8601Date";
>     /* String representation for a pipeline parameter. */
>     protected final String SDX_DATE_MILLISECONDS =
> "sdxDateMilliseconds";
> protected static final String[] _documentAdditionStatus =
> {"failure",
> "ignored", "added", "refreshed", "replaced"};
>     protected static final int DOC_ADD_STATUS_FAILURE = 0;
>     protected static final int DOC_ADD_STATUS_IGNORED = 1;
>     protected static final int DOC_ADD_STATUS_ADDED = 2;
>     protected static final int DOC_ADD_STATUS_REFRESHED = 3;
>     protected static final int DOC_ADD_STATUS_REPLACED = 4;
> 

vers?

> Question à propos propriétés : à quoi sert désormais la
> GetStringFromHashTable ? Le design semble privilégier le
> transtypage, non ?

C'est juste une méthode utilitaire...

> Autre point tout à fait mineur, plutôt que CheckX, on pourrait
> préférer
> EnsureXIsValid ?

J'ai pensé à verify(Object object) mais j'avais déjà utilisé le nomenclature 
"check" ailleurs.....Comme vous voulez?????

> En gros, on a 3 goupes : les noms XML, les propriétés et las
> constantes.

Il y a déjà 

fr.gouv.culture.sdx.utils.configuration.Node

peut-être il faut tout deplacer dans fr.gouv.culture.sdx.utils.constants comme:

fr.gouv.culture.sdx.utils.constants.Node
fr.gouv.culture.sdx.utils.constants.Configuration.Node
fr.gouv.culture.sdx.utils.constants.Context.Keys
fr.gouv.culture.sdx.utils.constants.Parameter.Name

Qu'en penses-tu?

> Désolé, c'est un peu en vrac, mais c'est pour montrer que je
> m'intéresse à
> ce qui se fait ;-)

Je veux bien t'investir pour cette factorisation aussi????:)


Rasik