sdx-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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
 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]