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

[Martin Sevigny]

Bonjour,

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

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.

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

C'est quoi un identifiant de classe/instance? Ca servirait à quoi?

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

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.

Je vois deux autres solutions :

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.

A bientôt,

Martin Sévigny