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

[Pierrick Brihaye]

Re,

Frédéric Glorieux a écrit:

> Je comprends mieux.

Je m'en réjouis :-) En fait, plus je réfléchis à la question, plus je me 
demande jusqu'où cette approche nous mènera...

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

Je vous promets un test case, mais il faudra attendre un peu : j'ai une 
appli très peu documentée, le développeur est difficile à joindre et le 
code source tarde à venir. M'enfin, j'arrive à interagir dessus en 
Javascript : proposer une API Java vers SDX ne devrait pas être très 
complexe... et puis, les décompilateurs, ça existe :-)

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.

> <!-- This code have not been tested yet -->
> <sdx:page>
>     <!-- TODO, could set an sdx_locations from params -->

Oui.

>     <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

Oui :-) C'est là où je me demande s'il ne serait pas possible d'avoir un 
paramètre (URL, nom de classe ou autre) qui serait capable d'exécuter du 
code pour alimenter le tableau ; un truc du genre :

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>

Oui.

>     <!-- 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 -->

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.

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.

>         <sdx:sort field="region" order="ascendant"/>

Oui. Peut-être faudrait-il aussi permettre le passage des clés de tri 
via des paramètres.

>      </sdx:results>
> </sdx:page>

L'idée est là en tout cas.

A+

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