Re: [sdx-developers] Representatiojn des resultats

[Pierrick Brihaye]

Re,

J'enfonce le clou avant le Carême :

Pierrick Brihaye a écrit:

> C'est là où je coince : personnellement, je tiens à ce que les résultats 
> restent encapsulés dans SDX ne serait-ce que que pour les regrouper par 
> page et, surtout, à partir de requêtes sur des moteurs différents, de 
> garder la logique applicative de présentation des résultats.

> Ce que j'aimerais bien pour la response, c'est avoir un mécanisme où 
> <wfs:FeatureCollection> est remplacé par <sdx:results> et où 
> <gml:featureMember> est remplacé par <sdx:result>. Bien sûr, SDX 
> paginerait la response, pour autant qu'on le lui ait demandé, et 
> ajouterait ses propres éléments (navigation p.e.).

Vous me direz, et vous aurez raison : "eh banane, si tu veux des 
résultats WFS, tu n'à qu'à interroger directement ton serveur WFS".

Oui mais voilà, ce concept d'encapsulation me tient à coeur :

En plus des arguments que j'ai déjà évoqués autour de la navigation, 
supposons que j'aie un résultat comme ça :

<gml:featureMember>
  <School fid="School.1">
  ....
</gml:featureMember>

... et que cet attribut "fid" me permette d'aller chercher des champs 
(oui ! des <sdx:field> tout ce qu'il y a de plus lucéniens) résultant 
d'une indexation Lucene. Vous voyez l'intérêt ?

Le "mécanisme" dont je parlais pourrait à vue de nez se résoudre via des 
pip... tubes : la requête étant le générateur avec, ensuite, toute une 
floppée de tranformations avant d'arriver au sérialiseur.

Martin me semblait évoquer une idée de cet ordre, non ?

Personnellement, je suis partisan, jusqu'à plus ample informé, que le 
sérialiseur soit *obligatoirement* un SDXResultsSerializer.

Bon, je pense avoir été clair sur les problématiques des résultats. A 
noter qu'elles sont totalement réversibles et applicables à la query :-)

A+

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