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

[Nicolas Maisonneuve]

>Mmmmh... pas convaincu. Les api-url proposent bien des queries, non ? Ce
>sont donc bien des générateurs :-)

qu'est ce que les api-url ?

>Ceci dit, ça n'exclut pas un flux en entrée, et donc de la
>transformation (la frontière est parfois très tenue) : un "deleter" aura
>sans soute besoin de générer une query pour déterminer le lot qu'il doit
>détruire.

la différence entre generator et transformor est simple , l'un accepte un
flux xml en entrée, pas l'autre
je ne comprend pas trop le doute sur le fait qu'il faut faire un
transformator  et non un generator
(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..)
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)

>Mmmh... ici, c'est délicat. Il y a un gros problème de fond car j'ai
>l'impression que tu veux des sdx:results *formatés*, c'est à dire
>filtrés, triés et paginés. Pour moi, c'est à un autre transformer de
>faire ça : ça permet de cacher les results ou, plutôt, les queries. BTW
>: c'est l'une de mes grandes interrogations du moment : que cacher ?

pour le pagination,  cache,  sur les resultats.. faire cela avec un autre
composant avalon qui sera utilisé dans le transformeur OK  mais un autre
transformeur , faux ..  car le transformateur seul ne
servira à rien ..   donc c'est pas un bon model de conception.. il faut que
cela soit caché en interne,
encore une fois le block lucene propose des débuts de piste..

le but n'est vraiment pas de réinventer la roue .. juste d'améliorer ce
block (enfiin c'est ce que moi je ferais ;-)


> 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

l'espace de nom est de tout facon obligatoire (a cause de la possibilité
d'avoir plusieurs transformeurs de différentes natures a la suite)

donc votre idée c'est : on met des balises vides qui se rempliront ..quel
est l'interet ?
Cette pratique dans les transformer n'est pas spécialement connue ..mais bon
peut être y'a til un intêret qui m'echappe ?

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


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

>   <parsedQuery parser="org.truc.queryParser">
> +ddd:xxx +(eee:xxx fff:xxx -(ggg:xxx) hhh:xxx) +iii:xxx
>   </parsedQuery>

pas besoin de faire un parser , perf au top , mais pas XMLisé..

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

ok donc là on est dans du bas niveau .. (souple)
l'inconvénient du bas niveau c'est qu'il require des traitements en amont,
donc la question est :
comment est formé ce fragment xml a partir du niveau utilisateur (champs de
saisie etc..)?
Avec un queryGenerator ? .. oula .. ca complique les choses ..
(je ne parle pas du passage des paramettre de recherches mais du traitement
a faire pour crréer cette structure apres avec eu connaissance de ces
paramettre de recherche)

A+


----- Original Message -----
From: "Pierrick Brihaye" <address@hidden>
To: <address@hidden>
Sent: Friday, September 12, 2003 12:45 PM
Subject: Re: RE : [sdx-developers] SearchTransformer..un peu d'aide


Re,

Frédéric Glorieux a écrit:


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


> Le modèle de Pierrick pour formuler une requête complexe est
> certainement plus compréhensible que celui actuellement dans la taglib

:-) Et surtout, il me paraît plus puissant... v. la problématique des
complexop dans [sdx-users]. Je n'ai toujours pas compris :-(


> <sdx:results>



>   <sdx:locations/> ou indexes ?

Je propose : indexSet :-)))

>   <sdx:sort/>
>   <sdx:filter/>

Nous y voilà : cf. plus haut.

> </sdx:results>

> En entrée, <sdx:locations/>, <sdx:query/>, <sdx:sort/>... sont
> prescriptifs.
> En sortie, ils sont descriptifs.

La formule est jolie : je la resortirai :-)

> Pour la navigation dans une page de résultats,
> Il me faut en entrée un <sdx:results id="q4" page="5"/>

Un fois de plus, un problème se pose : à quoi correspond "q4" ? A la
query j'imagine... mais moi, j'aurai peut être envie de travailler avec
la 5ème page de résultats *filtrés* de telle manière (f141) et/ou triée
de telle autre (s2456).

Si l'on considère que l'on a :
query -> results
results -> filter
filter -> sort
sort -> paging

... on peut gagner pas mal de performance en cachant le flux ad hoc, non ?

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

Oui. On aurait un QueryGenerator à passer dans un
QueryExecutorTransformer :-) Délicat pour une complexQuery...

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

Oui. C'est pour ça que si un tel composant est développé... on pourrait
le prendre : la taglib sera toujours capable d'en tirer parti (via un
protocole interne sdx:/ ?)



>
> C'est une approche très différente, beaucoup de développements,
> reste à savoir ce que cela apporterait en plus.
>
>
>
> _______________________________________________
> sdx-developers mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/sdx-developers
>
>


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



_______________________________________________
sdx-developers mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/sdx-developers