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

[Martin Sevigny]

Bonjour,

> 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

OK, c'est un peu ce que j'imaginais, mais je me suis toujours demandé à
quoi pouvait servir une référence d'objet ainsi? On peut retrouver un
objet en connaisant cette information? Comment? Ou autre chose? C'est un
peu hors sujet mais ça m'intrigue...

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

Ce n'est pas un problème de le copier. C'est un problème si, voulant
profiter de cette copie éventuelle, on voulait y ajouter d'autres
informations non SDX et que ces informations avaient du mixed content.
Dans ce cas, je crois qu'il y aurait un problème lors de la
configuration de l'application dans SDX.

Quant à sortir ce qui est réellement instancié, je ne sais pas. Ca
revient à programmer un toSAX() qui envoit presque le application.xconf,
mais pas toujours exactement. Est-ce que ça en vaut vraiment la peine?

J'aurais plutôt tendance à dire "Mettez ce que vous voulez dans .xconf,
ça pourra être restitué à la sortie, mais pas de mixed content. Il y a
aussi un hide="true" si vous voulez cacher des choses".

> application.xconf = objets instanciés avec succès + ERROR + WARNING 
> (essentiellement les modèles mixtes).
> 
> Très pédagogique, n'est ce pas ?

Ce serait l'avantage...

> 1) Je suis maître de mon installation SDX :-)

Oui, je m'en doutais, mais je le mentionnais parce que dans le
développement de SDX nous avons très souvent réfléchi à la facilité de
déploiement d'une application sur un serveur qu'on ne maîtrise pas,
d'une part, et qu'on ne veut pas corrompre ou modifier.

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

Si tu le dis. Mais je repose ma question : quelles sont les possibilités
offertes par les identifiants d'instances?

A bientôt,

Martin Sévigny