Re: [sdx-developers] Feature request ?

[Frédéric Glorieux]

Je crois que je ne comprends pas.
Mais en répondant points par points, peut-être que de la lumière viendra
pour l'un ou l'autre.

> 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);
> >         }

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.


> <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" />

Si les résultats sont toujours les mêmes, je ne vois pas l'intérêt d'un
objet results,
il suffit d'une xsl qui parse proprement un fichier long
(attention aux performance). Genre
<xsl:param name="hpp" select="20"/>
<xsl:param name="n" select="1"/><!-- paramètre xsl du curseur dans la liste
de datas, peut être fixé par paramètre http si sitemap configuré -->
<xsl:for-each select="document('mydata.xml')/datas/line[(position() &gt;=
$n) and (position() &lt; $n+$hpp)]">
<!-- inclure un doc sdx selon un id de data -->
    <xsl:copy-of select="document(concat(/sdx:document/@api-url, 'get?',
'app=myapp', 'base=mybase', 'id=', @id)"/>
</xsl:for-each>

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

Il s'agit juste que le formulaire de recherche (simple, avancé ...) peut
être à de nombreux endroits.
Mais c'est bien la page de destination (results.xsp) qui prépare la requête
selon les
paramètres HTTP envoyés.
Alors, la même xsl (sans logique selon la provenance) affiche les résultats
obtenus.
La limite est peut-être dans l'explication de la requête, on
pourrait aimer garder par exemple un formulaire de recherche avancée à
l'écran,
 pour ajuster sa requête sans perdre ses paramètres. Mais il s'agirait alors
que d'un
import de l'xsl de formulaire de recherche.

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

Tes résultats changent-ils selon une interaction avec l'utilisateur ?
Auquel cas le XML que tu veux faire parser par la taglib serait écrit dans
l'XSP,
et serait changé à chaque requête, et donc le texte de l'xsp changeant,
l'xsp serait recompilée.
Si ce texte ne change jamais, il serait mieux traiter par tes soins en xsl
avec document().
S'il peut changer, il suffirait que le fichier parser par document() soit
une xsp qui fabrique le xml
selon les paramètres url.

> En fait, on aboutit au concept de requêtes (query) externes à SDX...

> Il est d'ailleurs intéressant de noter que j'ai proposé
> <sdx:createResults> car je me plaçais du côté du côté du concepteur
> d'applications. En tant que développeur SDX, j'aurais dû proposer
> <sdx:executeExternalQuery> :-))

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. Sinon, faudrait-il commencer à
passer des
signature de classes en espérant qu'elles répondent bien à nos interfaces ?
A cet endroit je pense
que SDX ferait trop pour surtout compliquer Cocoon.

Mais il y a certainement beaucoup d'éléments qui m'échappent dans le but
visé.