Re: [sdx-developers] Feature request ?

[Frédéric Glorieux]

Pour la taglib ceci devrait marcher (charger la toute dernière version)

<sdx:results sf="champ_de_tri" so="asc"/>

Les résultats affichés sont ceux de la dernière requête construite,

variable courante sdx_query.

Le mot <sdx:results/> s'ouvre actuellement sur un sdx_results=sdx_query.execute();

sauf qu'une requête n'e'st exécutée que si rien n'est caché.

 

Dès maintenant tu peux utiliser l'API XSP si tu as un objet (Query)sdx_query

qui répond un objet Results à la méthode execute().

genre

<sdx:page>

    <xsp:logic>

    sdx_query= (fr.gouv.culture.sdx.search.lucene.query.Query)myquery;

    </xsp:logic>

    <sdx:results/>

</sdx:page>

Si tu voulais une autre logique, donne un exemple de code généré (tomcat/work/...)

(Dans la taglib, je préfèrerais en commentaires)

 

 

----- Original Message -----

From: Pierrick Brihaye

To: address@hidden

Sent: Tuesday, September 03, 2002 7:00 PM

Subject: [sdx-developers] Feature request ?

Bonsoir,

 

Je compte me mettre assez vite sur un redéploiement d'application vers SDX2 mais auparavant, je voudrais formuler une feature request. J'espère qu'elle n'existe pas déjà :-)

 

Voilà : je voudrais générer des sdx:results sans nécessairement passer par une requête SDX via des tags du genre <sdx:createResults>, <sdx:createResult id="xxx">... L'idée sous-jacente est de permettre l'interfaçage depuis des appli externes (reuqêtes spatiales par exemple ;-). Bien sûr, ces sdx:results bénéfécieraient ensuite des fonctionnalités offertes par le framework, en particulier un éventuel caching, l'insertion des champs brief des documents inclus et - peut-être  aussi - un (re)tri sdx.

 

Quels sont les problèmes que poseraient à priori l'implémentation de cette fonctionnalité ?

 

p.b.