Frédéric Glorieux wrote:
> 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. 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 ? 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.
Pour la question des multiples sorties : c'est un peu la meme question
que de se demander pourquoi en Java, une fonction ne retourne qu'une
valeur, et pas par exemple une liste de valeurs, de meme qu'on a une
liste de valeurs passes en parametre. Certains langages supportent
d'ailleurs cette possibilite. Lorsque ce n'est pas le cas, on hacke,
par exemple en Java, on va faire Object[] myFunction(), ou void
myFunction(Object[] o), etc. pour arriver au meme resultat. Cas
relativement rare, mais qui arrive.
Pratiquement, avec Presentation Server, on utilise plusieurs documents
de sortie en standard avec les page models. Un modele peut retourner
un document a passer a la vue, mais on veut aussi la possibilite de
mettre a jour l'instance XForms. En consequence, le modele peut
exposer une sortie "data", mais aussi une sortie "instance". Sans
cela, on devrait implementer deux pipelines, ou recourir a des hacks
comme faire de l'agregation (meme cas qu'en Java !).
Un autre exemple est celui du T (tee), i.e. un processeur qui
reproduit sur plusieurs sorties le document de son entree. Ceci n'est
uilise qu'en interne par XPL puisque le teeing est built-in dans XPL,
mais un tel processeur existe effectivement (TeeProcessor).
L'interet de multiples entrees est plus evident que celui de multiples
sorties, mais il existe tout de meme bien des applications. Supporter
ceci rend aussi le langage plus orthogonal.
-Erik
--
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 Sun Sep 26 04:15:32 2004
