[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[sdx-developers] RE : Application.toSax()
From: |
Martin Sevigny |
Subject: |
[sdx-developers] RE : Application.toSax() |
Date: |
Wed, 30 Oct 2002 12:43:40 +0100 |
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