Re: RE : [sdx-developers] Change ments récents

[Pierrick Brihaye]

Re,

>> 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...

OK. A mettre dans les Tasks :-)

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

>Que veux-tu dire ici?

... que les keys de repositories devraient être dans le package repository,
les keys de documentBase dans lee packahe documentBase, etc, etc.

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

J'aime bien :-) Ou PropertiesKeys. Ou Constants. Ou ApplicationConstants. V.
p.e. http://cocoon.apache.org/2.1/apidocs/allclasses-noframe.html où... ce
n'est pas très cohérent :-)

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

J'aime moins.

>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.

Je comprends bien. En revanche, si seul le package xxx de SDX m'interesse,
j'aimerais bien que la plupart de ses dépendences, idéalement toutes soient
dans ce package.


>> 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?

Constants :-)

>> 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?????

Pas facile. On peut laisser comme ça. Je me demande d'ailleurs si je ne vais
pas faire une RFE Java qui pourrait donner des signatures comme ça :

public notnull String getString();
public setString(notnull String aString);

Ca nous faciliterait la tâche, non ?

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

>Il y a déjà

Oui, c'était un résumé.

>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?

V. plus haut mais ça me paraît satisfaisant.

>> 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????:)

Très dur en ce moment : je cours 150 lièvres à la fois. Mais, promis, je
vais voir ce que je peux faire.

A+

p.b.