Re: RE : RE : [sdx-developers] QueryParser : ...et toujours

[Pierrick Brihaye]

Re,

Pierrick Brihaye a écrit:

> Donc, tu as raison, c'est bien à la requête d'aller chercher son 
> QueryParser... et l'analyseur utilisé par le dit QueryParser.

Récapitulons. On va se placer dans le cas le plus complexe, celui d'une 
"simple"Query :

le développeur devrait pouvoir :

- passer un QueryParser
- par défaut, utiliser le QueryParser du fichier de configuration

En ce qui concerne l'analyseur utilisé par ce QueryParser (ou de celui 
utillisé par une FieldQuery), le développeur devrait pouvoir :

- passer un Analyzer
- par défaut, utiliser l'analyseur du QueryParser par défaut (TODO. 
ISSUE : quel analyseur utiliser si la QueryParser *n'est pas* 
l'analyseur par défaut ?)
- par défaut, utiliser l'analyseur du champ par défaut (ISSUE#1 : le 
champ par défaut en recherche *peut-il* être différent du champ par 
défaut en indexation ? v. plus bas. ISSUE#2 : quel est le champ par 
défaut si on a plusieurs locations ?)
- par défaut, utiliser l'analyseur de la fieldList (TODO : laquelle si 
on a plusieurs locations ?)
- par défaut, utiliser l'analyseur... par défaut :-), i.e. celui codé en 
dur dans SDX.

A priori, disposer d'un champ par défaut en recherche différent du champ 
par défaut en indexation n'a pas beaucoup de sens *mais* le code actuel 
offre cette intéressante possibilité qui sert essentiellement pour la 
représentation textuelle des requêtes ; je pense qu'il faut conserver ce 
concept... et aller jusqu'au bout dans ce domaine (v. mes posts 
précédents sur l'absence de libellé de champ dans les représentations 
textuelles des requêtes).

Note : la dynamique de highlighting devrait êgalement suivre le même 
procédé dans le principe.

N'ai-je rien oublié ?

A+

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