On Mon, 2004-09-27 at 00:00, Sylvain Wallez wrote:
> 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.
Oui, c'est apparu clairement lors de mes essais : lorsque j'utilise
"cocoon:" l'exécution de ce pipe est faite dans un contexte "neuf" alors
que lorsque j'exécute un pipe Presentation Server toutes les opérations
se réalisent dans le même contexte.
En pratique, lorsque j'accède au pipe "rss" dans Cocoon via "cocoon:rss"
je dois ajouter à cette adresse la query string (et je serais bien en
peine de lui passer des paramètres par un autre mécanisme) alors lorsque
j'accède au pipe "rss.xpl" de PresentationServer, ce pipe est exécuté
dans le même contexte et connaît la query string.
Comme le dit Erik, c'est une différence sémantique. Dans le cas que je
cite, cela m'aide mais il y a d'autres cas où le fait d'exécuter un pipe
dans un autre contexte pourrait être mieux adapté.
Enfin, Erik précise bien que nous parlons "indépendamment de strategies
de caching", mais il est évident que lorsqu'elles s'appliquent, elles
réduise les différences de performances enter ces deux approches.
> 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.
C'est également visible dans mes derniers essais : le pipe "rss.xpl"
utilisé pour renvoyer un résultat de test comme réponse HTTP ne peut pas
être utilisé comme "sous-pipe" pour alimenter l'envoi de cette réponse
en XHTML puisqu'il n'a pas de sortie. Il a donc fallu que je définisse
un pipe avec sortie générant le résultat sous forme RSS et que j'utilise
ce pipe avec sortie dans les pipes envoyant le résultat sous forme RSS
et XHTML.
Avec Cocoon, j'utilise le même pipe cocoon:rss en direct et pour
conversion en XHTML.
Eric
--
Weblog:
http://eric.van-der-vlist.com/blog?t=category&a=English
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
--
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 08:06:03 2004
