Re: RE : [sdx-developers] Feature request ?

[Frédéric Glorieux]

Je comprends mieux.

Ceci pourrait marcher très vite,
 mais il faudra tester à distance la taglib

<!-- This code have not been tested yet -->
<sdx:page>
    <!-- TODO, could set an sdx_locations from params -->
    <sdx:locations>
        <sdx:location app="a" base="a"/>
    </sdx:locations>
    <xsp:logic>
        String[] ids;
        // up to you to get them
        // up to you to strip the process (if heavy) when cached results are
requested
        String q="";
        for (int i=0; i < ids.length; i++)
            q+=" sdxdocid:"+ids[i];
        (SimpleQuery) sdx_query=new simpleQuery();
        sdx_query.enableLogging(sdx_log);
        sdx_query.setUp(sdx_locations, q);
    </xsp:logic>
    <!-- TOTEST -->
    <sdx:results qid="myQuery"><!-- if you precise your own id of query,
results are cached, but SDX will not touch them, others cached results are
"last in last out" in limit of 5 by default -->
        <sdx:sort field="region" order="ascendant"/>
     </sdx:results>
</sdx:page>

Ceci rentre tout à fait dans la logique actuelle de la taglib,
ouvrant le plus qu'il est possible des variables stables tout
au long du process.
Ce serait long à documenter, mais on peut laisser des snippets sur
cette liste.

----- Original Message -----
From: "Pierrick Brihaye" <address@hidden>
To: <address@hidden>
Sent: Thursday, September 05, 2002 10:00 AM
Subject: Re: RE : [sdx-developers] Feature request ?


> Salut,
>
> Martin Sevigny a écrit:
>
>   > Pour moi oui à tout le moins : je n'avais pas compris que les
résultats
>   > externes n'auraient que des ID et que les brief seraient en SDX. Les
ID
>   > de tes resultats seraient des ID d'une base SDX, c'est ça?
>
> Euh... oui, sinon je ne vois pas comment faire :-)
>
> En sous-jacente de tout ça, on ("je" en fait...) en arrive à un  concept
> qui n'avait été perçu comme tel jusqu'à maintenant : un objet Results
> *est* un DocumentSet.
>
> En tant que tel, il peut offrir des possibilités d'implémentation
> intéressantes, notamment sur le tri. Pour reprendre l'exemple de listes
> statiques : on crée une liste de documents dans un ordre aléatoire, on
> la transforme en Results, et on la trie suivant le dernier algorithme en
> date. Beaucoup plus facile et générique que d'avoir à trier cette liste
> à la main ou de la constituer avec une requête Lucene de 150 kilomètres
> de long... surtout si les algorithmes de tri ne sont pas encore bien
fixés.
>
> Pour le passage dans la taglib, c'est peut-être plus facile une fois
> l'objet (re)mis en place mais il faudrait trouver des solutions
> élégantes ; celles que j'ai proposées ne le sont pas forcément...
>
> Il est certain que la construction de l'objet sera dispendieuse en
> performances, mais ce prix ne sera à payer qu'une fois ; tout nouvel
> accès à l'objet Results bénéféciera ensuite de l'instance créée.
>
> C'est pour cela que j'ai proposé cette approche car je me vois mal
> confier le tri et le paging à mon appli externe... et encore, je ne
> compte pas la mise au point des xsp capables de communiquer avec elle et
> qui seront propriétaires.
>
> Autre avantage : les champs brief restent synchronisés avec la dernière
> indexation SDX. Là encore, la synchronisation entre SDX et l'appli
> externe n'aurait peut-être pas été de la tarte.
>
> On pourrait encore aller plus loin sur ces champs brief et construire un
> objet Results qui serait le merging, éventuellement conditionnel, des
> champs brief de SDX et de champs "brief" de l'appli externe, mais là, ça
> attendra :-))
>
> Pour l'implémentation, je garde ta proposition sous la main. C'est un
> objet qui m'est encore peu familier, surtout si on le "délucénise" :-)
>
> A+
>
> --
> Pierrick Brihaye, informaticien
> Service régional de l'Inventaire
> DRAC Bretagne
> mailto:address@hidden
>
>
>
>
>
> _______________________________________________
> sdx-developers mailing list
> address@hidden
> http://mail.freesoftware.fsf.org/mailman/listinfo/sdx-developers