RE : [sdx-developers] SearchTransformer..un peu d'aide

[Frédéric Glorieux]

> Question idiote : ce n'est pas un Generator ?! Qu'est-ce 
> qu'il transforme ?

Je pense que c'est une bonne idée de penser un fournisseur de résultats
comme une transformation d'une requête formulée en XML.


> <search>
>   <!-- les endroits où chercher -->
>   <!-- v. MultiSearcher Lucene -->
>   <indexes>
>     <index id="aaa">
>     <index id="bbb">
>     <index id="ccc">
>   </indexes>
>   <!-- une jolie combinaison de requêtes -->
>   <group operator="and">
>     <search field="ddd" value="xxx"/>
>     <group operator="or">
>       <search field="eee" value="xxx"/>
>       <search field="fff" value="xxx"/>
>       <group operator="not">
>         <search field="ggg" value="xxx"/>
>       </group>
>      <search field="hhh" value="xxx"/>
>     </group>
>     <search field="iii" value="xxx"/>
>   </group>
> </search>
> 
> ou alors, version "on peut tout dire avec une ligne de texte" 
> : <search>
>   <!-- les endroits où chercher -->
>   <!-- v. MultiSearcher Lucene -->
>   <indexes>
>     <index id="aaa">
>     <index id="bbb">
>     <index id="ccc">
>   </indexes>
>   <!-- la même que la précédente -->
>   <!-- si je ne me suis pas trompé -->
>   <parsedQuery parser="org.truc.queryParser">
> +ddd:xxx +(eee:xxx fff:xxx -(ggg:xxx) hhh:xxx) +iii:xxx
>   </parsedQuery>
> </search>

Le modèle de Pierrick pour formuler une requête complexe est
certainement plus compréhensible que celui actuellement dans la taglib
(implantation un peu trop vite faite, qui aurait du rester discrète).
C'est un gros morceau à réfléchir.

Plus globalement, sur le XML en entrée, je proposerais l'idée que cela
ressemble le plus possible au XML en sortie, et que le transformer
agisse comme un xinclude intelligent. L'espace de noms sdx fournit déjà
un bon cadre. Je propserais donc que le conteneur soit
<sdx:results>
  <sdx:locations/> ou indexes ?
<!-- au fait, la sortie SDX des résultats pourrait nous donner les
endroits où ils ont été cherchés ? -->
  <sdx:query/>
  <sdx:sort/>
  <sdx:filter/>
</sdx:results>
N'est-ce pas des résultats que l'on veut ? Au transformeur de remplir
les trous.
En entrée, <sdx:locations/>, <sdx:query/>, <sdx:sort/>... sont
prescriptifs.
En sortie, ils sont descriptifs.
Pour la navigation dans une page de résultats,
Il me faut en entrée un <sdx:results id="q4" page="5"/>

        Au niveau d'un sitemap ma page search.xsp s'occupe de récupérer
des paramètres de formulaires pour composer le <sdx:results/> d'entrée,
au milieu du XML qui lui plait. Le transformeur de requête grossis le
tag <sdx:results/> avec ce qu'il en comprend. 

        Cela ressemble bigrement au travail de la taglib, à la
différence que l'on en contrôle le stade dans un processus de pipe. Au
lieu d'une XSL qui génère une fois pour toute un java plurôt lourd
destiné à être une XSP, cela consisterait plutôt à avoir un filtre SAX
qui intercepte les éléments sdx:*, pour les remplacer par d'autres
sdx:*, selon les paramètres passés.

        C'est une approche très différente, beaucoup de développements,
reste à savoir ce que cela apporterait en plus.