Erik Bruchez wrote:
>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 pense avoir mal exprimé ma remarque : les serializers dans Cocoon
définissent la nature du flux binaire qui va représenter le document XML
final. Cela peut être aussi simple que du texte ou aussi compliqué que
du JPEG (à partir de SVG), du PDF (XSL-FO) ou de la musique au format
Midi (si, si, à partir d'un document XMidi).
Le serializer ne s'occupe que de produire le flux binaire, sans
s'occuper de ce qu'est réllement ce flux binaire. Cette préoccupation
est celle de l'environnement. Cela peut être aussi bien la réponse http,
un fichier, un blob en base de données, un document CVS, un repository
WebDAV, le contenu d'un mail, etc (tout ceci existe actuellement dans
Cocoon).
Cette séparation permet ensuite d'explorer toute la combinatoire : on
peut parfaitement envoyer un mail dont le contenu est un pipeline
produisant du HTML, avec des attachements PDF et Midi produits
dynamiquement.
C'est parce que OPS n'a pas cette distinction serializer/environnement
que ses serializers sont classés par flux de sortie (cf
http://www.orbeon.com/ois/doc/processors-serializers) et non pas par
fonctionnalité. Par exemple, le serializer PDF n'existe qu'en version
réponse http et on ne peut donc pas produire un fichier PDF sur disque,
contrairement à Cocoon où le résultat d'un "cocoon:" peut être envoyé
n'importe où.
Petit détail pratique : cette distinction permet à un pipeline interne
(une URL appelée uniquement via "cocoon:" dans un scenario nominal)
d'être appelée depuis un navigateur, ce qui est très utile en phase de
développement.
>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.
>
>
Allons un peu plus loin sur un élément essentiel de l'architecture de
Cocoon : toute URL se résoud en un objet "source", qui définit une
méthode d'accès à un contenu, et n'est pas liée à la nature de ce
contenu. Dans sa forme la plus basique, une source ne donne accès qu'à
un InputStream. Mais cette interface de base a des extensions
(optionnelles) supportant l'écriture (cf blob, fichier, CVS et autres
mentionnés ci-dessus) et... l'accès à un flux XML pour les systèmes
fournissant un accès XML natif. C'est le cas d'une base xmldb (protocole
"xmldb:") et de "cocoon:".
Le choix entre les deux facettes du protocole "cocoon:" (binaire et XML)
dépend de l'environnement d'utilisation. Lorsqu'une URL "cocoon:" est
utilisée dans un contexte XML (comme l'aggrégation ou le générateur
"file"), sa production est le flux SAX qui entre dans le serializer du
pipeline. On a donc dans ce cas un vrai chaînage SAX des pipelines.
Cette notion de source et de protocole étendu permet d'avoir des
architectures très souples, puisque qu'on accède aux sources de données
uniquement avec des URLs. Si le système doit évoluer par exemple d'un
stockage en filesystem vers un stockage en blob, les changements
consistent seulement en une mise à jour des URLs (on peut aussi avoir un
protocole virtuel de type "mount-table" rendant l'application totalement
étanche à ces changements).
Ces URLs étendues sont utilisées *partout* dans Cocoon, à chaque fois
qu'on a besoin d'accéder à un flux de données. C'est valable pour le
générateur "file" (bien mal nommé, puisqu'il s'agit en fait d'une URL),
les XSL, le source des XSP et même celui des sitemaps ou des flowscripts
(code javascript).
>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.
>
>
D'après ce que j'ai compris, l'exécution d'un XPL passe par un "chaînage
arrière", en partant des serializers (sans output) et en remontant les
relations input -href/output-id jusqu'au(x) générateur(s).
Comment (question de newbie) peut-on dans ce cas choisir le type de
production en fonction de l'entête http user-agent ?
Voici comment on ferait avec Cocoon :
<map:match src="{1}.hml">
<map:generate src="{1}.xml"/>
<map:transform src="doc2html.xsl"/>
<map:select type="browser">
<map:when test="xhtml-compliant">
<map:serialize type="xhtml"/>
</map:when>
<map:otherwise>
<map:serialize type="html"/>
</map:otherwise>
</map:select>
</map:match>
Le selecteur "browser" permet d'associer des patterns sur l'entête
user-agent à des noms symboliques comme ici "xhtml-compliant".
>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.
>
>
Ah. Voici la confirmation de ce que j'exprimais précédemment.
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 Tue Sep 28 10:18:19 2004
