Re: [sdx-developers] Feature request ?

[Pierrick Brihaye]

Re,

>Dans l'état, il suffit que ton objet Results soit castable en
>fr.gouv.culture.sdx.search.lucene.query.Results
>(en attendant un jour une l'interface plus générique dont Martin parlait).
>L'essentiel me semble-t-il, c'est que l'objet ait les méthodes.

On est d'accord. C'était une note en passant : ne pouvait-on concevoir que
l'objet Results soit générique dans SDX, qu'il soit généré par Lucene ou
autre chose ?

Pour clarifier mon propos sur ces fameux Results :

Je voudrais avoir la possibilité d'avoir des <sdx:results> *strictement*
identiques à ceux issus de Lucene.

Pourquoi identiques ? Parce que ces résultats, bien que fournis par une
application externe, sont *sémantiquement* identiques à ceux de Lucene et
donc transformés de la même façon qu'eux. Une liste d'enregistrements, est
une liste d'enregistrements ; peu importe comment on les a trouvés... bref,
il faut faire en sorte que SDX considère ces Results comme s'ils provenaient
de SDX lui-même alors qu'en fait ils ont été générés par des applis
externes.

Le problème, c'est que mes appli externes :
- ne renverront généralement *que* les id des documents
- n'auront généralement pas connaissance des valeurs brief qui, par
définition, sont pourtant retournées dans les résultats
- ne trieront généralement pas les résultats et, en aucun cas selon des
préoccupations documentaires.

Le truc est donc de mettre au point un mécanisme qui instancie un objet
Results à partir d'une ridicule liste d'ids. Le problème n'est pas si simple
car il faut, par exemple, aller chercher les valeurs brief qui, elles, sont
stockées dans SDX.

>Si les résultats sont toujours les mêmes, je ne vois pas l'intérêt d'un
>objet results,

Si. Ca peut être intéressant pour le combiner avec d'autres requêtes, pour
le trier et, d'une façon générale, pour n'avoir à gérer qu'une
transformation, celle de <sdx:results>, au lieu de plusieurs.

>Mais qui va interpréter ce tag ? S'il s'agit juste d'inclure du XML venant
>d'une URL, il suffit d'utiliser le xinclude de cocoon.

On est d'accord. Mais avec l'instanciation d'un objet Results on
bénéficierait ipso facto de toutes les facilités offertes par SDX. J'en vois
4 immédiates par ordre décroissant d'importance :
- tri (après tout, mes applis n'ont qu'à le faire eux-même :-)
- caching (c'est vrai qu'on peut inclure assez facilement un objet dans la
session mais il est plus délicat de gérer son lifecyle en externe ; dans
SDX, on sait à quoi s'en tenir)
- inclusion des champs brief (qui d'autre que SDX pourrait le faire ?)
- combinaison avec d'autres Results (sous-requêtes bâties avec des API SDX)

On bénéficie ainsi de *toutes* les API SDX (génériques) au lieu d'avoir à
rédiger des XSP plus ou moins complexes qui, d'ailleurs, seraient
probablement très tributaires des applis. Gros gains en temps de
développement, en formation...

Voilà. J'espère avoir été plus clair.

p.b.