Re: [sdx-developers] Feature request ?

[Pierrick Brihaye]

Salut,

>Ce qui me vient à l'esprit :
>
>- les Results sont essentiellement construits autour de Hits (classe
>Lucene) : ils offrent des services comme la pagination, le tri, la
>XMLisation des résultats

Nous sommes d'accord.

>- par conséquent, si on veut ce genre de choses, il faut permettre de
>constuire des objets Results autrement que par l'exécution d'une requête
>Lucene

C'était la question :-)

>La meilleure approche (je pense) serait de créer une classe qui étend
>Results, avec des méthodes d'alimentation différentes. Quand on regarde
>les méthodes de la classe, ce n'est pas un grand défi :
>
>* Results(), enableLogging(), setUp pour construire

Cela va de soi...

>* count(), countPages() pour des infos sur le nombre de pages

A choper en examinant les <sdx:result> créés.

>* getDocIds() pour retourner les identifiants des documents

Injectés grâce à <sdx:createResult id="xxx">....

>* getMaxScore() (s'il n'y a pas de pertinence on retourne une
>constante...)

En l'occurence, on retournerait une constante. Quoique...

>* getNavigationAsSAX() pour donner des indications sur les documents
>précédents et suivants

OK. C'est là où l'on gagnerait avec une approche objet.

>* getQuery() => retourne une Query SDX, utilisé seulement par
>AbstractQuery pour des basequery

Il peut être intéressant d'injecter la requête d'origine, un truc du genre :
<sdx:createResults query="isInPolygon(4,0 5,1 3,2 -1,-12 -127,2)>
... en ajoutant éventuellement un attribut queryEngine = "SpatialEngine"
(vs. LuceneEngine)

>* reSort() pour retrier

C'est là où c'est plus délicat : <sdx:createResults> injecterait des
résultats potentiellement non triés. De plus, il pourrait injecter plus de
résultats que l'on n'en affiche généralement sur une page. Au-delà des pbs
SDX, ça pose le pb de l'espace mémoire.

>* setAllHits() et setHitsPerPage() pour le nombre de pages

OK. C'est la notion de "page" qui me dépasse un peu. Comment transformer une
xsp en lui injectant 10.000 résultats, non triés qui plus est, alors que le
nombre de pages par défaut est de 20 ? Il faudrait instancier l'objet et ne
ressortir que les N premiers après tri, ce qui impose a priori 2 passes.

>* setId() pour donner un identifiant à la requête (appelé par la taglib)

OK.

>* toSAX() pour sortir une représentation XML

OK. Ici, il est indispensable de reprendre le même schéma. C'est pour ça que
je tiens à rester dans SDX :-)

>C'est envisageable pour ton type de résultat?

Ben oui :-) Aux 2, 3 détails près....

>Evidemment, avant de faire cela, il faudrait être orienté objet : on
>définirait une interface Results, qui aurait une implantation Lucene et
>ton implantation. Cette interface aurait les count(), docIds(), les
>SAX(), setId() et reSort(), ou quelque chose comme cela.

OK.

>Ensuite, si je comprends bien, tu veux manipuler cela par l'API XSP?

Eventuellement... ou en Java natif. Mais de but en blanc, je pense que le
xsp serait possible.

>Ca me fait penser à quelque chose : dans sdx:results, il faudrait
>retourner un attribut tel que "type" avec valeur "lucene" (pour
>l'instant)...

Oui. V. plus haut. Merci pour cette réponse, les choses deviennent plus
claires...

A bientôt. Sur ce point ou un autre...

p.b.