Re: RE : [sdx-developers] Application.toSax()

[Pierrick Brihaye]

Re,

Martin Sevigny a écrit:

Je vais répondre sur les 2 paragraphes ; de mon point de vue, ça 
participe de la même logique.

> C'est effectivement une des approches qu'on avait imaginée. Je souligne
> un point (dont les détails sont à confirmer, mais dans l'esprit c'est
> juste) : le application.xconf est lu par les outils de configuration XML
> de Avalon, et ces outils n'aiment pas les mixed content. Je le
> mentionne, parce que ça pourrait être intéressant de mettre des infos
> hors namespace SDX dans ce .xconf, mais ce n'est pas aussi souple qu'on
> le voudrait.
>
> C'est quoi un identifiant de classe/instance? Ca servirait à quoi?

La classe de l'objet désigné par l'élément de configuration :

Si tu as <sdx:repository id="users" type="FS" baseDirectory="users/xml" 
depth="0" extent="1000"/>, le Framework crée un objet de la *classe* 
fr.gouv.culture.sdx.repository.FSRepository identifié par une *instance* 
address@hidden Bref, un truc très 
comparable avec ce qui est actuellement fonctionnel avec les sdx:user, 
sdx:parameter... (et que je trouve excellent, je le rappelle)

Ca donnerait donc, dans le toSAX() un élément :

<sdx:repository id="users" type="FS" baseDirectory="users/xml" depth="0" 
extent="1000" class="fr.gouv.culture.sdx.repository.FSRepository" 
value="address@hidden" />

En ce qui concerne le modèle mixte dans les objets de configuration, je 
vois bien que c'est un problème :-) On aurait pu, pour cette méthode 
toSAX(), copier bêtement l'élément <sdx:application> dans 
application.xconf. Ca n'est à mon avis pas souhaitable et il faudrait 
sérialiser selon ce qui a été *réellement* instancié.

Pour caricaturer :

application.xconf = objets instanciés avec succès + ERROR + WARNING 
(essentiellement les modèles mixtes).

Très pédagogique, n'est ce pas ?

> 1) Dans le xconf, avoir un attribut booléen, disons "hide" pour
> l'instant, qui indiquerait les parties à "cacher" (c'est comme les
> "include" que tu donnes en exemple, mais à l'envers et ailleurs)
> 2) Dans la XSP, on a prévu un mécanisme avec un attribut "show" (je
> crois) qui pourrait prendre une liste de valeurs, valeurs qui indiquent
> ce qu'on veut que SDX sorte. Ca peut être une façon de contrôler cet
> aspect
>
> Cette deuxième solution est bien sûr dynamique : showString, show,
> showParam, etc.

Les solutions proposées me semblent bonnes.

Points de doctrine :

> Tu réfléchis comme quelqu'un qui est maître de son installation SDX et
> des applications qui y tournent ;-) Si on met ça dans le xconf, ça
> signifie que c'est vrai pour toutes les applis. Un hébergeur n'aimerait
> pas ça.

1) Je suis maître de mon installation SDX :-)
2) La mise à disposition de ce type d'infos, en particulier les 
identifiants d'instances dans la JVM me paraissent *effectivement* 
relever de la responsabilité de l'hébergeur car les possibilités 
induites sont énormes. L'hébergeur pourrait par exemple avoir envie de 
cacher ses systèmes de fichiers, ses SGBD et même son identité.
3) Tout ça relève plutôt de SDX 3 :-)

A bientôt.

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden