Erik Bruchez wrote:
>Eric van der Vlist wrote:
>
>
>
>>Est-ce tellement plus complexe :-) ???
>>
>>
>
>C'est un debat... Mais la syntaxe Cocoon impose clairement plus de contraintes
>(ou mettre l'aggregation, par exemple), et si le pipeline devient encore plus
>complexe, je vois la lisibilite aller en decroissant. Pourquoi une agregation
>est-elle limitee a la generation ? Tres arbitraire comme choix.
>
>
C'est vrai, le <map:aggregate> est limité à la génération. Mais on peut
aussi utiliser le transformer XInclude.
>Une question : est-ce que lors de l'execution du pipeline, la premiere
>transformation (ci-dessous) est executee une fois, ou deux ?
>
><match pattern="transform-output-1">
> <generate src="/my-input-file.xml"/>
> <transform src="/my-stylesheet1.xsl"/>
> <serialize type="xml"/>
></match>
>
>Il y a en effet deux references a "cocoon:transform-output-1". Je veux dire
>bien sur independament de strategies de caching (imaginons que cette
>transformation opere sur la sortie d'une requete a une base de donnees, par
>exemple). J'ignore sincerement la reponse a cette question. Si la reponse est
>deux executions, alors nous avons une difference semantique importante avec XPL.
>
>
Une petite réponse très rapide (désolé, en ce moment je n'ai vraiment
pas le temps de suivre vos discussions fort intéressantes).
Oui, le "transform-output-1" est effectivement exécuté 2 fois.
Rapidement, à propos des sorties multiples. Dans Cocoon, une URL
"cocoon:" (i.e. le résultat d'un pipeline) est considérée exactement
comme les autres, et on peut donc faire des tas de choses avec, en
particulier enregistrer son résultat où bon nous semble (sur une autre
URL "writeable" par exemple). Pour cela, Cocoon fournit l'action
"copy-source" et la commande flowscript "processPipelineTo(url,
outputstream)".
Mais ce ne sont pas de vraies sorties multiples, puisqu'il s'agit en
fait d'exécutions de pipelines indépendantes.
J'ai lu la doc de Orbeon Presentation Server (OPS?), et ce qui me manque
vraiment (outre le flowscript), c'est la notion de serializer,
indépendant du support de sortie. D'après ce que j'ai compris, un
serializer OPS est un processor sans outputs. Le problème est qu'il
définit non seulement *comment* le document XML est sérialisé, mais
aussi *où* on l'envoie (fichier, réponse http, etc).
A mon sens, ces notions doivent être séparées. C'est le cas dans Cocoon
et c'est ce qui permet de prendre la sortie d'une URL "cocoon:" pour en
faire ce que bon nous semble.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
--
Devenez redacteur <XML>fr et contribuez au developpement du
xml francophone (http://xmlfr.org/infos/redacteurs/) !
Liste de diffusion "dev@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet technique lie au developpement du site XMLfr.
Pour resilier votre abonnement, envoyez un message contenant
la commande "unsubscribe" a dev-request@xmlfr.org
(mailto:dev-request@xmlfr.org?Subject=unsubscribe)
Received on Mon Sep 27 00:00:47 2004
