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

[Pierrick Brihaye]

Bonjour,

Nicolas Maisonneuve a écrit:

> qu'est ce que les api-url ?

http://www.nongnu.org/sdx/docs/html/doc-sdx2/fr/migration/api-url.html

> la différence entre generator et transformor est simple , l'un accepte un
> flux xml en entrée, pas l'autre

C'est clair :-)

> je ne comprend pas trop le doute sur le fait qu'il faut faire un
> transformator  et non un generator

Un generator prend des paramètres :

search?query=field:value

Un transformer pourrait prendre du SAX :

<lucene:group operator="and">
<lucene:query field="aaa" value="xxx"/>
<lucene:query field="bbb" value="xxx"/>
<lucene:group>

Libre à l'appli de décider qui génère ce SAX.

> (a moins que l'on veuille faire passer les requetes de recherche par un
> autre format que le XML, style request comme c'est le cas dans le
> SearhGenerator de cocoon ou les parametres sont passés dans une requete HTTP
> mais c'est pas super.. puisqu'on perd pas mal de possibilité
> d'utilisation..)

C'était le propos :-)

> de toute facon , le generator ou le transformor utilisent en interne
> plusieurs composants
> avalons... donc  le generator/tranformer n'est que le haut de l' iceberg
> comme je precisais dans le premier mail c'est le composant maitre c'est le
> LuceneCocoonSeacher  ..  (VOIR Block Lucene)

On est d'accord. V. aussi les commentaires de Rasik sur les objets Java 
: il est assez délicat de savoir quels composants pourraient/devraient 
les utiliser. On peut en reparler :-)

> le but n'est vraiment pas de réinventer la roue .. 

Le problème est plus délicat : Lucene propose ses propres filtres. SDX 
propose les siens et, d'une manière générale, je pense que tout 
XXXSeracher qui se respecte devrait in fine laisser à l'utilisateur la 
possiblité d'appliquer son propre filtre an plus ou à côté des filtres 
Lucene. Dans l'idéal, on devrait bien sûr pouvoir faire les 2.

> > Si l'on considère que l'on a :
> > query -> results
> > results -> filter
> > filter -> sort
> > sort -> paging
>
> dans le teme filter , y'a quoi exactement ..?

Ici, je parle d'un filter externe à Lucene qui a déjà ses résultats. V. 
plus haut.

> pour en revenir à l'entree XML :
>
> j'aime bien l'idée de mettre en attribut la class parser  à l'utiliser
> (comme le IndexTransformer où on peut mettre la classe analyzer à employer)
> un truc du genre <search class="org.truc.parser"></search>

En fait, il vaudrait sans doute mieux mettre cette classe (ou un "hint") 
sur les éléments <parsedQuery>, mais on peut aussi concevoir un parseur 
global.

> en ce qui conernce le segment <group>...</group>
> (petit question d'ailleurs  xxx dans votre example..
> requete XMLisé , besoin de faire son propre parser, performance surement
> réduite

Le parsage prend normalement peu de ressources.

> au fait le xxx est un seul terme c'est ca ?

N termes quelconques.

> comment est formé ce fragment xml a partir du niveau utilisateur (champs de
> saisie etc..)?

Par exemple. Fred en est le spécialiste :-)

> Avec un queryGenerator ? .. oula .. ca complique les choses ..

Avec un producteur de flux quelconque : ça peut être un 
table_des_matieres_automaisee_generator, un 
liste_des_articles_interessants_generator... c'est pour ça que les 2 
approches Generator/Transformer devraient être possibles.

[snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] 
[snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] 
[snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] 
[snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] 
[snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] 
[snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] 
[snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] 
[snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] 
[snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip] [snip]

A bientôt,

p.b.

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