RE : RE : RE : RE : [sdx-users] A propos du pipeline d'indexation dynamique

[Frédéric Glorieux]

> > sur l'attribut qid="" 
> OK. Je crois que beaucoup serait preneurs d'un exemple :-)

Comme toujours le plus long n'est pas d'implanter mais de tester, j'y
pense en démo sdxtest.

> > Et pourquoi ne pas simplement utiliser la sitemap cocoon, pour
fournir
> > le document transformé par l'XSL d'indexation?
> 
> C'est effectivement dans l'esprit. Mais... pour reprendre un exemple
> récemment cité, si on confie la génération d'id à la XSL... on va se
> retrouver avec une id qui n'aura rien à voir avec celle effectivement
> pertinente. On peut aussi avoir des problèmes des des documents
> "attachés" qui ne seraient plus disponibles.

Juste, là on en demande un peu plus à SDX. Il faudra voir à ouvrir le
pipe d'indexation en sitemap, v3?

> > Pour l'encodage URL, on
> > pourrait se suffire de ce qu'il y est possible en XSL (s'il on ne
> > demande que ça à SDX).
> 
> Je suis d'accord. Pense-tu que ça pourrait intégrer les XSL mises à
> disposition par SDX ? J'ai bien peur que chacun ait déjà rédigé un
> snippet de code XSL d'encodage. On pourrait donc mutualiser ?!

Dans sdx-default.xsl? Je crois que cela y fut un jour, mais il m'a
semblé que ce fut retiré parce qu'il y avait des caractères qui
plantaient dans certains systèmes (j'espère que je n'ai pas perdu le
snip). 

> 
> >>Disposer d'une action SDX à même de générer une vue XML *partielle*
> >> des résultats, un truc du genre <sdx:includeResult qid="xxx"
n="yyy"/>
> 
> > ??? est-ce le même objectif que l'attribut @show qui permet par
exemple
> > d'avoir une liste de résultats, sans <sdx:field/>, ni <sdx:results/>
ou
> > <sdx:result/> (pratique pour des exports)?
> 
> Mmmh... ici, il s'agirait plutôt de définir des éléments frères de
> <sdx:includeDocument/>, un truc du genre :
> 
> <sdx:includeDocument id="xxx"/>
> <sdx:includeResultDocument relative_to="xxx" in_query="yyy"/>
> <sdx:includeIndexationDocument relative_to="xxx"
in_documentbase="zzz"/>
> <sdx:includeWhateverRelatedDocument relative_to="xxx" from="aaa"/>
> 
> J'avoue que je suis insidieusement de poser les jalons de SDX 3 :-)))

        D'abord, je crois qu'aucune syntaxe ne pourra prévoir tous les
états possibles d'un doc. Ceux qui utiliserais tes noms, ce seraient les
mêmes qui voudront ensuite, "mon doc à l'état initial mais pas celui
conservé par sdx, et avec la transformation 4, mais pas la 3". 
        Il m'arrivera probablement de monter un jour des pipelines longs
(quand on veut par exemple utiliser des XSL standards ou des filtres
SAX), mais alors, je me sentirais mieux d'avoir une syntaxe de pipe
accessible en sitemap cocoon. Ainsi pour tes demandes, il faudrait un
générateur du doc (includeDocument), et vérifier les classes SDX pour
les utiliser en transformers.
        Je ne comprends pas bien tes attributs relative_to="xxx",
in_documentbase="zzz", in_query="yyy". Dès maintenant, si tu veux le
document n de la requête cachée yyy, il te suffit d'écrire

<sdx:results qid="yyy"/>
<sdx:show n="15"/>

Donne moi un cas, et on testera si ça ne marchait pas bien. Je vois
qu'on pourrait aussi avoir avantage à demander, 

<sdx:show n="15" hpp="37"/>

Pour avoir de 15 à 52. Dans l'état ça ne marche pas, mais on pourrait
faire tourner.

> Le problème, c'est que la méthode d'encodage utilisée par SDX est
> deprecated sur certaines JVM.
> Les puristes risquent de ne pas aimer :-)

C'est vrai, il y a une alternative en 1.4 (avec précision de l'encodage
en résultat), mais du coup on ne tourne plus en 1.3 (ce que je fis un
jour pour le malheur des autres).


> je reste persuadé que l'un des atouts
> indéniables de SDX est de proposer une programmation entièrement basée
> sur XSP.

Que la taglib rende des services cohérents, avec une syntaxe logique,
c'est déjà difficile à maintenir. Pour d'autres choses, peut-être que
cela peut prendre une place dans une autre taglib?