RE : [sdx-developers] fieldParam

[Martin Sévigny]

Salut,

> Suite à mes déboires de ce AM (v. [sdx-users], 
> xsp:attribute), je me demande s'il ne serait pas opportun 
> d'ajouter à <sdx:executeFieldQuery>, 
> <sdx:executeExactFieldQuery>, <sdx:executeDateIntervalQuery> 
> et <sdx:executeRestrictedQuery> un attribut "field" qui 
> permettrait d'éviter l'indirection induite par l'attribut 
> "fieldParam" ?!

Il faut généraliser un peu. J'avais pensé (pour SDX 2 a priori, mais on
peut l'intégrer à SDX 1 aussi) de faire en sorte que tout ce qui pouvait
(actuellement) provenir de la request pourrait aussi être codé en dur.
Parfois c'est possible, d'autres fois non. Je crois que cette approche
inclut le besoin de Pierrick énoncé ci-haut.

Cet aspect suppose que l'on peut définir les paramètres (en dur) dans
des sous-éléments, pas seulement des attributs, pour permettre plusieurs
occurrences (par exemple pour les clés de tri).

Par ailleurs, il y a d'autres détails à ajouter à cela, tant qu'on en
parle :

- tout ce qui est requête de recherche ou liste de termes, il devrait
être possible d'exécuter la recherche mais de ne pas l'inclure dans le
document XML dynamique, ce qui permettrait par exemple de vérifier les
résultats avant de les retourner, pour refaire une requête différente ou
je ne sais trop quoi. Aujourd'hui, on a besoin de l'API Java mais
seulement parce que SDX inclut automatiquement les résultats

- pour faciliter encore plus le point précédent, on devrait permettre de
spécifier le nom de la variable Java qui contiendrait le résultat de
recherche, dans le but de la réexploiter dans la XSP (en Java) sans
avoir besoin de lire sdx.xsl pour savoir quel est le nom de la variable

- actuellement, si j'ai plus d'une requête de recherche dans une XSP, ça
ne compile pas, parce que les variables Java seront définies plusieurs
fois. Il faudrait suffixer ces variables par un nombre qui serait la
position de l'élément <sdx:execute...Query/> dans la XSP, pour éviter
tout ambiguité

Pour faire cela, il faut réécrire la taglib au complet, car à peu près
tout est codé en dur, il faut factoriser beaucoup le code et le
généraliser un peu.

J'aurai d'autres suggestions pour la taglib, des petites choses mais qui
peuvent être intéressantes. Je vous en reparlerai, si vous avez des
idées aussi n'hésitez pas.

A bientôt,

Martin Sévigny