Sylvain Wallez wrote:
> Oui, le "transform-output-1" est effectivement exécuté 2 fois.
(Ceci est discute plus loin dans cette thread, donc je ne commente pas
ici.)
> 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.
J'essaie de comprendre un peu les implications, surtout negatives pour
Presentation Server, de ceci. Avec XPL, il n'y a pas de standard pour
definir comment on peut implementer un serialiseur. On a juste un
processeur qui n'a pas de sortie XML (SAX), comme correctement note.
Mais je ne vois pas vraiment de probleme. On a un serialiseur par type
de sortie, e.g. HTTP, File, etc. Si on veut reutiliser un pipeline, on
definit juste un pipeline avec une sortie, sans serialiseur, et on
appelle ce pipeline depuis d'autres pipelines. Il n'y a alors pas de
concept de serialisation necessaire lors de l'appel du premier
pipeline, puisque la sortie du pipeline est un stream d'evenements SAX
(je devrais peut-etre plutot dire un infoset XML puisque SAX est un
detail d'implementation).
Je comprends certains use cases lies au protocol "cocoon:", et j'y
pense encore, mais il faut voir qu'avec XPL, on a cet autre moyen (et
qui est le moyen unique en principe) de referer aux sorties d'un
pipeline qui ne requiert pas du tout la serialisation en stream et/ou
l'utilisation d'un URL.
Admettons qu'on ait un document XHTML, et qu'on veuille l'envoyer a un
browser soit en XHTML, soit en HTML. On ecrit un pipeline qui genere
le document en question, puis on appelle ce pipeline depuis deux
courts pipelines, l'un qui serialise selon la methode HTML vers HTTP,
l'autre selon la methode XML vers HTTP, avec les parametres de
configuration (DOCTYPE, etc.) necessaires dans chaque cas.
Le nom des serialiseurs est peut etre un probleme (XML Serializer,
HTML Serialiser). Il s'agit en fait dans tous ces cas du HTTP
Serializer. Ce serializer permet d'etre configure pour serialiser en
un stream XML, HTML ou texte. Comme raccourci, on a cree des
sous-classes du HTTP serializer qui automatiquement met le serialiseur
en mode XML, HTML ou texte. On a donc principalement un serialiseur
par destination:
o File Serializer pour des fichiers
o HTTP Serializer pour servlet / portlet (qui inclut les serialiseurs
XML, HTML et texte)
o URL Serializer pour les destinations URL ecrivables ("file:",
"oxf:")
o Etc.
Tous prennent une meme configuration de base, avec extensions (par
exmple, on doit specifier un nom de fichier avec le File Serializer,
mais dans ce cas un status code n'a pas de sens).
-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 Mon Sep 27 23:39:38 2004
