Re: [sdx-developers] Feature request ?

[Pierrick Brihaye]

Salut,

Frédéric Glorieux a écrit:

> Actuellement, le code en taglib qui réalise ces opérations est celui-ci
>         sdx_object=session.getAttribute("sdx_" + sdx_qid);
>         if (sdx_object != null && sdx_object instanceof
> fr.gouv.culture.sdx.search.lucene.query.Results)

Premier point à noter : mes results  ne feraient probablement pas partie 
du package Lucene :-) Le couplage entre le moteur de requête (Lucene) et 
la classe Results est-il si fort que ça ?

>         {
>
> sdx_results=(fr.gouv.culture.sdx.search.lucene.query.Results)session.getAttr
> ibute("sdx_" + sdx_qid);
>              sdx_results.toSAX(contentHandler, sdx_qpage);
>         }

OK.

> Une fois une requête exécutée, l'objet results obtenu est caché en session.

Bien. C'est précisément cette fonctionnalité qui m'intéresse, à savoir 
profiter de toute la logisitique SDX.

> Cet objet sait répondre la page demandée selon le hitsPerPage qui a été fixé
> avant la mise en cache en session.

Oui.

> Il faut essentiellement que l'objet results sache répondre. S'il s'agit d'un
> retour SQL il n'est probablement
> pas judicieux que tous les résultats soit stockés en mémoire, pourvu que la
> méthode results.toSAX()
> sorte la bonne série d'événements selon les possibilités de la source de
> données.

On est d'accord. Mais ça m'oblige à externaliser mon code ; c'est ce que 
je cherche à éviter (mais je reconnais que ça ne serait pas compliqué à 
mettre en oeuvre) en intégrant la fonctionnalité dans la taglib.

> Ici je comprends moins bien.
> Souhaiterais-tu une XSP du genre
> <sdx:createResults query="isInPolygon(4,0 5,1 3,2 -1,-12 -127,2)"
> type="spatial">
>     <sdx:createResult id="1">
>     <sdx:createResult id="2">
>     <sdx:createResult id="3">
> ...
> </sdx:createResults>
> ???

C'est exactement ça. On pourrait ajouter une spécification de tri et une 
définition d'id pour le jeu de résultats.... afin de pouvoir la 
réutiliser. Poursuite de la démonstration en XSP pseudo-SDX :

<sdx:createResults id="myid" query="isInPolygon(4,0 5,1 3,2 -1,-12 
-127,2)" type="spatial">
  <sdx:createResult id="1">
  <sdx:createResult id="2">
  <sdx:createResult id="3">
   ...
</sdx:createResults>
<!-- on trie les résultats -->
<sdx:sortResults id="myid">
  <sdx:sort>champ 1</sdx:sort>
  <sdx:sort>champ 2</sdx:sort>
</sdx:sortResults>
<!-- on les affiche -->
<sdx:showResults id="myid" page="5" hpp="12" />

Le but du jeu serait de définir dynamiquement le jeu de résultats et de 
l'exploiter *immédiatement* dans la même XSP. Après passage dans la 
taglib, ça me donnerait un truc tout à fait classique :

<sdx:page>
  ...
  <sdx:results query="myid" ...>
    <sdx:result id="1">
     <sdxfield>field 1</sdx:field>
    </sdx:result>
    <sdx:result id="2">
     <sdxfield>field 2</sdx:field>
    </sdx:result>
    ...
  <sdx:results>
</sdx:page>

Note : un gros avantage est, également, de récupérer les champs brief 
des documents qui, eux, sont internes à SDX et sont probablement 
inconnus de l'appli qui a généré le jeu de résultats.

Tout ça est un peu différent de l'implémentation traditionnelle des 
applis SDX (en tout cas, celles d'AJLSM ;-)) qui ont 2 XSP, l'une qui 
"prépare" la requête, l'autre qui montre ses résultats 
(sdx:execute*Query>). Ici, je veux bel et bien faire les 2 dans la 
*même* XSP. On a donc une composante *séquentielle* forte dont je me 
demande si elle est compatible avec le modèle évènementiel de Cocoon 2.

> Tu voudrais que quelquechose dans la taglib s'occupe de parser ça  pour
> créer un objet results ?

Oui :-)

> Mais cela veut dire une xsp dynamique qui serait compilée à chaque fois ?

A priori non. De but en blanc - mais je ne connais pas très bien la 
nouvelle taglib - l'implémentation n'est pas très éloignée de ce que 
fait par, exemple, un <sdx:execute*Query>. Ceci dit, il faut que je 
creuse encore la question pour savoir dans quelle mesure le dynamique ne 
serait pas intéressant.

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