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

[Frédéric Glorieux]

> >         <sdx:sort field="region" order="ascendant"/>
>
> Oui. Peut-être faudrait-il aussi permettre le passage des clés de tri
> via des paramètres.

Prévu, tous les attributs SDX ont au moins trois noms
(ex pour field)
    @field="region" nom statique
habituellement, tout attribut réagit à un paramètre URL par défaut,
généralement le nom de l'attribut, sauf
quelques uns par commodité historique @query= > &q= ; @field= > &f= ;
@value= > &v=
    @fieldParam="sortby"
déconnecte le paramètre URL par défaut et scrutera &sortby=
    @fieldString="myStringVar"
fixe la valeur par ta variable java String myStringVar (si elle n'est pas
déclarée, erreur de compilation)

> Oui. Ca pose des problèmes connexes : il faudra peut-être un jour des
> API StoreResults/DiscardResults... avec des paramètres de session,
> d'utilisateurs, des timeouts, etc.

Avant de compliquer pour des usagers rares, une requête avec un identifiant
(qid) fixé par
le développeur d'application est rendue si disponible, sinon réexécutée et
recachée à la même
place (enfin c'est ce que cela doit faire, pas vraiment testé).

> BTW la sécurité des API Servlet ne permet plus depuis longtemps de
> partager des objets de session. Je me demande quelle serait la mesure la
> plus efficace pour pouvoir disposer de Results globaux... comme les
> listes statiques dont je parlais.

On a agité la question, le problème est en suspens ...
Il est vrai que pour une requête que nous dirons "statique", il n'est pas
judicieux que chaque
connecté en garde l'objet dans sa session. Il faudrait un mécanisme de cache
au niveau d'une application,
identifiée par exemple par une chaîne Lucene (cette cache serait à détruite
à toute mise à jour).

> L'idée serait d'avoir une interface (du style SDXResultsProvider) et une
> classe abstraite à surcharger pour chaque appli qui voudrait communiquer
> avec SDX. On verra ensuite si ça vaut le coup de les mettre dans les
> packages SDX. Je pense à un SDXResultsProviderFromSQL et,
> éventuellement, à un SDXResultsProviderFromWFS : Web Features Server, un
> standard de l'OGC qui transmet des entités géométriques en XML via des
> requêtes HTTP.

Martin semble avoir des idées sur le sujet.
Pour ma part, il me faudrait au moins une ou deux classes concurrente à
"LuceneResults",
afin de de définir un contrat commun le plus fourni possible.

> IdsFeeder feeder = Class.forName(<xsl:value-of
> select="@feederClass"/>).Newinstance();
> feeder.feedIds(ids);
>
> >         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>

Il y a bien sûr un problème de performances à constituer une requête avec
des données issues
probablement d'une requête, mais n'est-ce pas un choix SDX de garder
toujours accès à ses bases
par une simple chaîne (et donc une URL) ?