Re: RE : [sdx-developers] Migration

[Frédéric Glorieux]

Attention Pierrick avant de te baser sur les paramètres sortis par la
taglib, cette fonctionalités est encore susceptible de modification (selon
tes lumières). A l'usage il s'est avéré que sortir tous les paramètres peut
devenir très parasite. La dernière taglib (du genre 2 ou 3 jours), ne sort
plus que les paramètres en get (comme SDX-1) et <sdx:user/>. Mais tout peut
se configurer par une liste de valeurs dans un attribut @show sur l'élément
racine.
<sdx:page show=""/> --> n'ajoute plus rien
<sdx:page show="get user"/> --> comportement normal
<sdx:page show="get post put session headers objects"/> --> tous les
paramètres HTTP actuellement supportés par le wrapper cocoon de tomcat, avec
une mention particulière pour "objects", qui affiche le xml d'un objet de
session si celui-ci à une méthode toSax() (à utiliser avec précaution
parceque cela revient à afficher les 5 requêtes mise en cache par
utilisateur)
<sdx:page show="user application"/> --> les objets SDX actuellement
envoyables

Cette idée d'attribut @show est aussi implantée pour des résultats de
recherche
@show="documents" --> sortir les documents résultats d'une requête, sans
aucun tags SDX (export)
@show="documents results fields" --> équivalent de l'attribut @doc="true"

-------------------------------------------------------------------

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


| Oups ! Vu l'attribut "type" (request/session : y a-t-il d'autres valeurs
| possibles ?). Je vais donc utiliser les prédicats...

| Autre chose : dans ma vieille appli, je partais du principe que si je
| n'avais aucun paramètre, j'affichais une page par défaut. Désormais,
| c'est plus difficile car SDX ajoute des paramètres du style :
|
| <sdx:parameter name="sdx_user"
| class="fr.gouv.culture.sdx.user.AnonymousUserInformation"
| value="address@hidden"
| type="session"/>
|
| ou
|
| <sdx:parameter name="sdx_user"
| class="fr.gouv.culture.sdx.user.UserInformation"
| value="address@hidden" type="session"/>
|
| (ce qui prouve que je maîtrise désormais le login.logout ;-)
|
| Je trouve cette idée excellente et je me rends bien compte du parti que
| l'on peut en tirer. Cependant, n'est-il pas nécessaire de faire la
| distinction entre les paramètres fournis par la request (user-parameter)
| et ceux fournis par SDX (system-parameter) ? En l'état actuel des
| choses, les deux types sont confondus ce qui me pose un problème
| d'implémentation, chose tout à fait secondaire néanmoins :-)