[sdx-developers] Application.toSax()

[Pierrick Brihaye]

Re,

Je poursuis ma migration... sur sdx-developpers ;-)

Voilà : les xsp2gen me donnent une vision de plus en plus claire des 
choses. En particulier, je vois que le fait que la méthode 
Application.toSax() n'ait pas été implémentée me bride dans ce que je 
veux faire, y compris dans la simple reprise d'une appli SDX 1.

Personnellement, je ne vois aucun inconvénient à ce que cette méthode 
reprenne *trait pour trait* le schéma de application.xconf (i.e. 
<sdx:application> et tous ses enfants) : ça garantit la cohérence et ça 
a des vertus pédagogiques :-)

A vue de nez, le seul truc que l'on pourrait ajouter par rapport à la 
xconf, et ce n'est pas pressé, ce sont les identifiants de 
classes/instances des objets créés par le Framework.

Je conçois cependant que ça risque de charger xsp générées. Le problème 
n'est pas tant au niveau de la performance car j'imagine que Cocoon met 
ça en cache ou, à tout le moins, peut le mettre en cache.

Pour pallier cet inconvénient, on pourrait concevoir à l'avenir, par 
exemple dans sdx.xconf, de ne greffer que certains éléments... un truc 
du genre :

<sdx:xsp-context>
  <sdx:application-description include="true">
      <sdx:fields-description include="false"/>
      <sdx:database-description include="true">
        <sdx:repositories-description include="false" >
           <sdx:repository-description include="true" 
select="visible-repository-for-wich-I-want-some-info"/>
        </sdx:repositories-description>
      </sdx:database-description>
  <sdx:application-description/>
</sdx:xsp-context>

Voilà. Une bonne partie de ce post concernait les archives :-)

A+

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