|
From: | Nicolas Maisonneuve |
Subject: | [sdx-developers] SearchTransformer..un peu d'aide |
Date: | Thu, 11 Sep 2003 19:15:47 +0200 |
bonjour,
j'essaie en ce moment de faire un cocoon
seachIndexTransformer
le but étant de réécrire le code
SDX pour la recherche qui est fait pour etre utilisé en
taglib , en un transformer ..histoire de séparer un maximum ,
politique de cocoon (la separation des préoccupations (separation of concern),
d'ailleurs cocoon présente cela comme une separation des
travaux à faire entre développeur, designer, etc.., alors que c'est plus
général comme concept, très proche de l' Aspect oriented programming
AOP..enfin bon)
donc
- en entrée on aurait un truc du genre SDX
<page>
<search:simpleQuery
query="title:coucou"/>
ou
<search:complexQuery>
...
</search:complexQuery>
</page>
je ne sais pas trop justement ..
il faut que je reflechisse sur les use cases (avec SDX comme point de
départ)
d'ailleurs voilà un peu , comment je vois les choses : c'est pas
super reflechi mais bon
(en fait je ne connais pas trop les requetes SDX , linear, term, simple,
complexe... etc)
1 requete = une chainde de caractere saisie par l'utilisateur (= un
champ de saisie)
les possiblités sont :
Ensemble A:
( type fulltext donc .. avec un seul champs de saisie) A1: 1 requete sur 1 champ (champ=luceneField)
A2: 1 requete sur n champs
donc pour A2 , on peut voir un declaration du style :
(A1 étant inclu dans A2)
<query string=" couco~ l?s -amis">
<field name="title" boost="2">
<field name="description"/>
<field name="author"/>
..
</query>
(on rajoute un query spécial date su style : <querydate from=""
to="" >)
Ensemble B:
(type multicritere avec plusieurs champs de saisie)
B1: n requetes sur 1 champs
B2: n requetes sur n champs
Supposons que l'on peut voire B comme une combinaison d'ensemble A
(ce qui est pas juste mais bon )
operateur=NOT OR AND // par da
<multi:query>
<query string="coucou les amis" op="and"> //si omis alors operateur =
AND
<field name="title" boost="2">
<field name="description"/>
<field name="author"/>
</query>
<query string="coucou les amis 2" >
<field name="title2" boost="2">
<field name="description2"/>
<field name="author1"/>
</query> <multi:query>
donc on aurait , en résumé, une entrée de ce style :
<search indexbase="">
<multiquery>
<query string="coucou les amis" op="and"> //si
omis alors operateur = AND
<field name="title"
boost="2">
<field
name="description"/>
<field name="author"/>
</query>
<query string="coucou les amis 2" op="not">
<field name="title2"
boost="2">
<field
name="description2"/>
<field name="author1"/>
</query> <multiquery>
ou
<query string="coucou les amis 2" >
<field name="title2"
boost="2">
<field
name="description2"/>
<field name="author1"/>
</query>
ou <query string="coucou les amis 2" >
<field name="title2"
boost="2">
</query>
</search>
qu'en pensez vous .. ?
cela comble t'il tous les cas d'utilisation ? (aurais je oublié un cas
important)
- en sortie je me baserais sur le seachGenerator de cocoon
(xmlisation des resultats, gestion de la pagination) (peut être que le
développement dans SDX est mieux) le searchGenerator de
cocoon utilise plusieurs composants
dont LuceneCocoonSearcher
(\src\blocks\lucene\java\org\apache\cocoon\components\search)
le but sera d'ameliorer le composant
LuceneCocoonSeacher avec des requêtes plus
poussées de style SDX
et pourquoi pas aussi le LuceneCocoonPagers,
(SDX a peut être un mécanisme plus recherché pour la pagination)
ou autres composants en relations
j'aurais juste voulu avoir une petie aide
concernant votre code:
- savoir pourquoi avoir écrit un queryparser
, autre que celui proposé par lucene
- qu'est que le Criteria Filter
?
voilà merci d'avance
nico
|
[Prev in Thread] | Current Thread | [Next in Thread] |