Re: RE : [sdx-developers] SearchTransformer..un peu d'aide

[Pierrick Brihaye]

Re,

Frédéric Glorieux a écrit:


> > Question idiote : ce n'est pas un Generator ?! Qu'est-ce 
> > qu'il transforme ?
>
> Je pense que c'est une bonne idée de penser un fournisseur de résultats
> comme une transformation d'une requête formulée en XML.

Mmmmh... pas convaincu. Les api-url proposent bien des queries, non ? Ce 
sont donc bien des générateurs :-)

Ceci dit, ça n'exclut pas un flux en entrée, et donc de la 
transformation (la frontière est parfois très tenue) : un "deleter" aura 
sans soute besoin de générer une query pour déterminer le lot qu'il doit 
détruire.

> Le modèle de Pierrick pour formuler une requête complexe est
> certainement plus compréhensible que celui actuellement dans la taglib

:-) Et surtout, il me paraît plus puissant... v. la problématique des 
complexop dans [sdx-users]. Je n'ai toujours pas compris :-(

> Plus globalement, sur le XML en entrée, je proposerais l'idée que cela
> ressemble le plus possible au XML en sortie, et que le transformer
> agisse comme un xinclude intelligent. L'espace de noms sdx fournit déjà
> un bon cadre. Je propserais donc que le conteneur soit

> <sdx:results>

Mmmh... ici, c'est délicat. Il y a un gros problème de fond car j'ai 
l'impression que tu veux des sdx:results *formatés*, c'est à dire 
filtrés, triés et paginés. Pour moi, c'est à un autre transformer de 
faire ça : ça permet de cacher les results ou, plutôt, les queries. BTW 
: c'est l'une de mes grandes interrogations du moment : que cacher ?

>   <sdx:locations/> ou indexes ?

Je propose : indexSet :-)))

>   <sdx:sort/>
>   <sdx:filter/>

Nous y voilà : cf. plus haut.

> </sdx:results>

> En entrée, <sdx:locations/>, <sdx:query/>, <sdx:sort/>... sont
> prescriptifs.
> En sortie, ils sont descriptifs.

La formule est jolie : je la resortirai :-)

> Pour la navigation dans une page de résultats,
> Il me faut en entrée un <sdx:results id="q4" page="5"/>

Un fois de plus, un problème se pose : à quoi correspond "q4" ? A la 
query j'imagine... mais moi, j'aurai peut être envie de travailler avec 
la 5ème page de résultats *filtrés* de telle manière (f141) et/ou triée 
de telle autre (s2456).

Si l'on considère que l'on a :
query -> results
results -> filter
filter -> sort
sort -> paging

... on peut gagner pas mal de performance en cachant le flux ad hoc, non ?

>         Au niveau d'un sitemap ma page search.xsp s'occupe de récupérer
> des paramètres de formulaires pour composer le <sdx:results/> d'entrée,

Oui. On aurait un QueryGenerator à passer dans un 
QueryExecutorTransformer :-) Délicat pour une complexQuery...

>         Cela ressemble bigrement au travail de la taglib, à la
> différence que l'on en contrôle le stade dans un processus de pipe.  Au
> lieu d'une XSL qui génère une fois pour toute un java plurôt lourd
> destiné à être une XSP, cela consisterait plutôt à avoir un filtre SAX
> qui intercepte les éléments sdx:*, pour les remplacer par d'autres
> sdx:*, selon les paramètres passés.

Oui. C'est pour ça que si un tel composant est développé... on pourrait 
le prendre : la taglib sera toujours capable d'en tirer parti (via un 
protocole interne sdx:/ ?)



>         C'est une approche très différente, beaucoup de développements,
> reste à savoir ce que cela apporterait en plus. 
>
>
>
> _______________________________________________
> sdx-developers mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/sdx-developers


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