eric van der Vlist wrote:
> Je voudrais pouvoir utiliser une "sitemap" ou "page-flow" pour
> définir des composants réutilisables dans les pages (par exemple
> l'affichage d'un canal RSS) et donner suffisamment d'autonomie aux
> auteurs des pages pour qu'ils puissent de manière simple les
> réutiliser dans leurs pages.
> Admettons que j'écrive une page qui regroupe les informations sur
> Orbeon. Je voudrais que l'auteur de la page puisse facilement (en
> sans avoir à modifier la sitemap (au sens large) inclure dans sa
> page la liste des résultats de recherche sur Orbeon, l'index des
> articles sur le sujet, la description d'Orbeon, ...
> Avec mes "feuilles de style sans style", c'est simple : on rajoute
> dans un document XHTML standard (que l'on peut éditer avec un
> éditeur XHTML) des éléments spécifique par exemple (<document-rss
> href="..."/>) et la transformation XSLT fait le reste.
Je comprends tres bien l'idee. On peut aussi voir ceci comme
"implementer une tag library" (terminologie JSP mais qui a du sens),
ou chaque "tag" est interprete. Ici, (version Cocoon) l'implementation
du tag est faite en XSLT et appelle un pipeline par le biais de la
fonction document() et du protocole "cocoon:". Le document XML
resultant (eventuellement transforme) est inclu dans la sortie. Nous
avons donc les questions suivantes:
1. Comment implementer simplement une tag library dont les tags
retournent un document XML.
2. Comment rendre disponible a l'implementation d'une tag library des
resources declarees dans la "sitemap".
Avec Presentation Server, il n'y a pas de "sitemap" a la Cocoon a
proprement parler. Le Page Flow declare des "pages" accessibles de
l'exterieur, et non des pipelines. Il declare donc bien une carte du
site si on veut, mais qui est completement independante des
pipelines. Ceux-ci sont simplements des resources XPL sur disque par
exemple, au meme titre que des stylesheets XSLT. On peut imaginer en
tout cas deux strategies:
1. Comme avec Cocoon, appeler des pages du PFC (Page Flow). Ceci n'est
pas possible pour l'instant excepte avec le protocole "http:", ce
qui est inelegant et inefficace (et pose des problemes comme la
generation d'un URL correct avec host, port, contexte, etc.). On
pourrait par contre implementer un protocole qui permette d'acceder
au PFC.
2. Appeler un pipeline quelconque. L'avantage : tout pipeline
disponible comme resource peut etre appele. Le desavantage : on ne
declare pas d'une facon centralisee les pipelines disponibles.
J'ai rencontre une situation similaire avec Presentation Server
lorsque je voulais creer un ensemble de "tags" destines a afficher des
images, ce qui requiert l'appel d'une base de donnees. La solution que
j'ai retenue a consiste a genererer dynamiquement un pipeline avec
XSLT, base sur le document initial (ton document XHTML + tags). Le
pipeline genere depend des tags en question, et cree un pipeline qui a
son tour appelle d'autres pipelines. Par exemple, si on avait:
<xhtml>
<body>
<my:image id="123"/>
<br/>
<my:image id="456"/>
</body>
</xhtml>
On creerait dynamiquement avec XSLT un pipeline dans le genre:
<p:config>
<p:param name="input-document" type="input"/>
<p:param name="output-document" type="output"/>
<p:processor name="oxf:pipeline">
<p:input name="config" href="oxf:/backend/find-image.xpl"/>
<p:input name="image-id" href="aggregate('image-id',
#input-document#xpointer(string(//my:image[1]/@id)))"/>
<p:output name="image-info" id="id1"/>
</p:processor>
<p:processor name="oxf:pipeline">
<p:input name="config" href="oxf:/backend/find-image.xpl"/>
<p:input name="image-id" href="aggregate('image-id',
#input-document#xpointer(string(//my:image[2]/@id)))"/>
<p:output name="image-info" id="id2"/>
</p:processor>
<p:processor name="oxf:xslt">
<p:input name="config">
<xsl:transform>
<!-- With XSLT, replace tags with results from pipelines -->
<!-- XSLT is not necessarily the most efficient way to implement
this aggregation, but it works -->
<!-- ... -->
</xsl:transform>
</p:input>
<p:input name="data" href="aggregate('results', #id1, #id2)"/>
<p:output name="data" ref="output-document"/>
</p:processor>
</p:config>
En passant : si le document XHTML d'entree est statique, grace aux
mecanismes de caching, la definition du pipeline, bien que generee
avec XSLT, sera cachee egalement. L'execution du pipeline par contre
peut etre supposee non cachable puisqu'elle appelle un pipeline,
find-image.xpl, qui probablement depend du contenu d'une base de
donnees externe.
Si le probleme consiste a creer une tag library qui appelle des
pipelines, on pourrait imaginer :
<xhtml>
<body>
<my:pipeline href="oxf:/my-pipeline-1.xpl"/>
<br/>
<my:pipeline href="oxf:/my-pipeline-2.xpl"/>
</body>
</xhtml>
En supposant pour simplifier que par convention chaque pipeline a une
sortie appelle "data", on genere le pipeline suivant :
<p:config>
<p:param name="input-document" type="input"/>
<p:param name="output-document" type="output"/>
<p:processor name="oxf:pipeline">
<p:input name="config" href="oxf:/my-pipeline-1.xpl"/>
<p:output name="data" id="id1"/>
</p:processor>
<p:processor name="oxf:pipeline">
<p:input name="config" href="oxf:/my-pipeline-2.xpl"/>
<p:output name="data" id="id2"/>
</p:processor>
<p:processor name="oxf:xslt">
<p:input name="config">
<xsl:transform>
<!-- With XSLT, replace tags with results from pipelines -->
<!-- XSLT is not necessarily the most efficient way to implement
this aggregation, but it works -->
<!-- ... -->
</xsl:transform>
</p:input>
<p:input name="data" href="aggregate('results', #id1, #id2)"/>
<p:output name="data" ref="output-document"/>
</p:processor>
</p:config>
On est d'accord que ce mechanisme est lourd. On pourrait imaginer,
sans modifier Presentation Server, quelque chose de plus intelligent,
base sur un fichier XML qui configurerait la tag library. De cette
facon, l'interprete de tags serait generique. Par exemple, la
configuration pourrait etre comme suit :
<tag-library>
<tag>
<element name="my:image"/>
<pipeline href="oxf:/backend/find-image.xpl" output="data"/>
</tag>
<tag>
...
</tag>
</tag-library>
Reste a trouver une syntaxe pour de passer des parametres au pipeline
si necessaire, en se basant probablement sur les attributs du tag, ou
sur le body de celui-ci (toujours dans la terminologie JSP).
Quelques autres idees en vrac :
o L'interprete peut etre place dans l'epilogue.
o La question d'implementer un protocole a la "cocoon:", peut-etre un
protocole "pfc:" qui permette d'acceder aux pages du PFC, reste
ouverte.
o Pour faciliter l'ecriture de l'interprete et eviter de creer un
pipeline dynamique, on pourrait creer des fonctions accessibles
depuis XSLT :
1. Une fonction pour appeler un pipeline quelconque.
2. Une fonction pour appeler une page du Page Flow.
Fournir des fonctions au lieu d'un protocole permet de passer des
parametres plus complexes, comme des sequences de documents XML a
passer aux pipelines, ou des instances XForms lors de l'appel de
pages du PFC.
Pour l'instant, a moins de passer du temps a modifier Presentation
Server (et il faudrait encore passer du temps pour considerer
certaines question d'architecture), je suggere de creer ce fameux
interprete de tag qui appelle des pipelines et realise donc la
strategie "pull".
> Avec PresentationServer, je pensais trouver la même fonctionnalité
> avec la protocole "oxf:", mais ce n'est pas le cas.
Le protocole "oxf:" fonctionne comme une abstraction pour l'acces a
des "resources", c'est-a-dire par exemple pour abstraire des
protocoles tels que "file:", "http:", ou d'autres comme des resources
accessibles par le JAR ou WAR classloader, ou depuis WebDAV (a travers
Slide). Chaque protocole est gere par un "resource manager" separe. On
pourrait implementer un resource manager qui accede au PFC, mais bien
qu'on puisse cascader les resource managers, il n'y a pas moyen de
discriminer et d'appeler un resource manager particulier. Il faudrait
donc soit modifier la facon dont le protocole "oxf:" fonctionne, soit
creer un nouveau protocole comme "pfc:", mentionne plus haut.
> Un contournement consiste à utiliser le protocole http mais je ne
> suis pas certain qu'il n'y ait pas des conséquences sérieuses au
> niveau des performances.
Correct, comme mentionne ci-dessus ce n'est pas une tres bonne
solution.
> Un autre contournement consiste à générer dynamiquement le pipeline
> qui va constituer la page. Est-ce celui que tu conseillerais pour
> faire ce que je veux et est-ce que cela ne va pas considérablement
> alourdir les choses?
C'est effectivement plus lourd, mais une fois l'interptete programme,
on peut le voir comme un composant generique qu'on ne touche que
rarement. Du point de vue efficacite a runtime, ce ne sera pas
immediatement optimal, mais on pourrait dans une seconde phase, apres
prototypage XPL + XSLT, creer un inteprete comme un processeur separe
en Java, qui lui devrait etre beaucoup plus efficace que la
combinaison XPL + XSLT proposee plus haut.
Voila un bon sac plein d'idees ! Je suis sur que d'autres approches
peuvent etre suggerees. La discussion est interessante car le probleme
est tres generique (voir JSP !).
-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 Wed Sep 22 01:03:04 2004
