On Sat, 2004-09-25 at 23:01, Frédéric Glorieux wrote:
> > Concernant la linéarité des pipes Cocoon, les récentes expériences que
> > j'ai pu faire pour XMLfr me conduisent à penser que l'utilisation du
> > protocole "cocoon:" est un contournement extrêmement efficace pour gérer
> > des entrées multiples.
> >
> > Par contre, je vois moins comment gérer les cas où on pourrait avoir
> > besoin de sorties multiples.
>
> Dès lors qu'on accepte qu'une sortie soit une URI appelable, je ne vois
> pas la difficulté ou alors je manque le problème.
Oui :-) ... Cela n'est peut-être pas très courant, mais on peut imaginer
que l'on souhaite générer non pas une mais plusieurs sorties et que l'on
souhaite les traiter séparément avant une éventuelle recomposition.
Au passage, il faut noter que XPL a une vocation généraliste et cherche
à pouvoir être utilisé en dehors du cadre des applications Web qui ne
renvoient qu'un seul flux à leurs clients HTTP.
> Une sortie de pipe me
> donne un état, que d'autres pipes peuvent utiliser en entrée. Soit cet
> état à un intérêt à être publié (ex, un docbook après xinclude) et il
> faut s'y efforcer, soit il peut toujours ne pas être exposé (<pipeline
> @internal-only="true"/>). Ensuite avec un générateur en @src="cocoon:"
> je peut démarrer autant de fois que je veux sur cette sortie (ex
> docbook, pour >html, ou >fo>pdf). Cela ne suffit pas ?
Cela suffit tant que chaque composant du pipe n'a qu'une seule sortie.
> Je suis trop
> engagé pour être objectif mais cela rends mon sitemap comme une
> collection de segments, les aiguillages se faisant en entrée et en sortie.
>
> En contexte ligne de commande, cela revient à laisser une trace fichier
> d'un état (conservable ou supprimable), sur laquelle d'autres peuvent
> repartir.
>
> > * Le langage de pipeline Cocoon s'interdit d'accéder au contenu de
> > ce qui passe dans le pipe (il agit comme un facteur qui ne
> > regarde pas ce qui est contenu dans les enveloppes qu'il
> > achemine) alors que XPL est intrusif et donne accès (par XPath)
> > au contenu des documents qui passent dans le pipe.
>
> Si on veut intercepter une étape d'un tuyau, est-ce qu'on ne quitte pas
> l'idée de tuyau ?
Le tuyau n'est qu'une métaphore... il ne faut pas nécessairement s'y
limiter, toute métaphore a ses limites.
> Est-ce que cela ne signifie pas qu'il faut arrêter un
> tuyau plus tôt et d'en recommencer un autre ailleurs ?
C'est une réponse possible mais ce n'est pas la seule...
Eric
--
Read me on XML.com.
http://www.xml.com/pub/au/74
------------------------------------------------------------------------
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 Sat Sep 25 23:46:20 2004
