Re: [sdx-users] Re: surlignage en index (long)

[Pierrick Brihaye]

Bonjour,

address@hidden a écrit:

> Est-ce plus clair?

Oui... étant donné que je pense avoir compris qu'il s'agissait d'une 
appli très fortement inspirée de de sdxtest :-)

Pas de solution immédiate pour autant que j'aie vu, en tout cas, si on 
reprend l'organisation de sdxtest.

Voilà ce qui ce passe ;

1) dans glossary.xsp, on a ça :
<sdx:terms field="contenu" value="a*" hpp="-1">

Ce jeu de résultats a un identifiant (qid) : supposons que ce soit 
"termes" (même si, bien sûr, ça a une forme "q*") et gardons le pour 
plus tard.

Avec ces résultats, on va créer des URL : les termes à occurence unique 
pointent vers document.xsp, les termes à occurences multiples vers 
results.xsp.

2) commençons par "ce qui marche" : un terme multiple. On est donc sur 
results.xsp.

results.xsp *repose* une question :
<sdx:executeSimpleQuery base="sdxworld sdxdoc"> avec un paramètre "q" 
que l'on supposera égal à "bla".

Ce jeu de résultats a un identifiant. Supposons que ce soit "terme" 
(sans "s"). On le garde aussi mais pas longtemps : on va l'utiliser tout 
de suite.

3) Ensuite, on arrive dans document.xsp qui pose normalement une 
fieldQuery sdxdocid:id_du_document, tout ça étant naturellement transmis 
dans les paramètres.

*MAIS*, comme results.xsp transmet également le paramètre qid, "terme" 
donc, les résultats ne sont *pas* ceux de sdxdoc:id mais ceux de la 
simpleQuery que l'on vient d'effectuer dans results.xsp !

<aparté>
Ces fonctionnalité est intéressante car elle permet de reprendre de 
résultats existants. En revanche, elle induit facilement en erreur car 
on pense faire une fieldQuery et, en fait, on reprend une simpleQuery 
effectuée auparavant.

Franchement, je me demande si un élément <sdx:cachedQuery qid="xxx"> ou 
similaire ne serait pas plus approprié... Problème de fond IMHO !
</aparté>

Pour en revenir à notre affaire, on surligne les termes du jeu de 
résultats "terme" et donc "bla".

4) Comme nous commes malins, on va se dire que dans glossary.xsp, quand 
le terme est unique, on va générer une URL de ce type :

document.xsp?&id=xxx&n=bbb&qid=termes c'est à dire de passer 
l'identifiant du jeu de résultats de <sdx:terms> et de tenter de forcer 
la main de SDX en lui passant en plus l'id du résultat qui nous 
intéresse et, éventuellement, son numéro d'ordre dans le jeu de résultats.

On espère ainsi que la fieldQuery de document.xsp récupère le jeu de 
résultats de "termes" plutôt que d'effectuer la fieldQuery sdxdocid:xxx

Et là , manque de pot, ça ne tourne pas comme on veut pour une raison 
malheureusement très simple :

un résultat de <sdx:terms> n'est *pas* de type sdx_result mais un objet 
de type sdx_terms. Pour être encore plus clair <sdx:*Query> est 
différent de <sdx:terms>.

Ainsi :

sdx_object=null;
if (sdx_check(sdx_qid))
  sdx_object=session.getAttribute("sdx_" + sdx_qid);
// don't try to force query execute if there's no query
if (sdx_query == null) sdx_bool=false;
/* get cached results if there are and not force execute query */
if (sdx_object != null &amp;&amp; sdx_object instanceof Results
  &amp;&amp; !sdx_bool)
    {
//snip
sdx_results=(Results)sdx_object;
    }

n'est pas exécuté (car pas instance de Results) et laisse la place à :
if (sdx_results==null &amp;&amp; sdx_query != null) /* new results */
{
  sdx_results=sdx_query.execute();
...
}

c'est donc la requête (fieldQuery) qui est exécutée et, comme elle porte 
sur l'id, le seul surlignage possible... c'est l'id :-)

Quelles sont les solutions ?

La plus simple est de revoir document.xsp et d'avoir une compleQuery qui 
ferait à la fois une requête sur l'id du document *et* sur le terme 
recherché (qui serait, bien sûr, à refiler en paramètre). Le problème, 
c'est que l'on aura un surlignage des deux valeurs mais ça, la XSL peut 
le gérer.

Une autre solution serait de permettre au pipeline de surlignage de 
pouvoir exploiter un objet sdx_terms car, pour l'instant, il n'exploite 
que sdx_results.

On pourrait envisager de mixer sdx_terms et sdx_results dans un objet 
commun puisqu'ils ont des formes similaires. En revanche, leur 
sémantique est radicalement différente donc... c'est a priori gênant.

J'ajoute également, que ça rejoint (un peu) la problématique de :

> select figure, count(figure) from matable
> group by figure
> order by figure ASC; 

"figure" étant un terme, c'est bien sûr vers <sdx:terms> qu'il faut 
regarder.

Voilà , j'espère ne pas m'être planté dans l'analyse. J'ai dû éplucher 
pas mal de code pour comprendre. Pas trop gênant : j'étais justement 
confronté à un problème du même ordre.

Naturellement, toute suggestion sur les problèmes soulevés ici est 
bienvenue.

A bientôt,

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