Sylvain Wallez wrote:
> Honnêtement, on est toujours tranquilles dans notre coin... Mais
> bon, ne polémiquons pas.
Je comprends bien. Le role de challenger n'est pas facile...
> J'ai commencé à regarder le Presentation Server d'un oeil un peu
> plus curieux (je n'avais jamais dépassé les buzz-pages sur votre
> site) et je trouve l'approche intéressante bien qu'un peut trop
> puriste. Le tout XML, c'est bien, mais est-ce applicable à tous les
> types d'applications ?
En theorie non, bien sur (de meme que l'approche "tout Java" ne
fonctionne pas pour toutes les applications). Le probleme principal
est de determiner quel langage utiliser pour quel but. (En passant,
XSLT 2.0 (Saxon 8 ou 9) est un grand pas en avant. Cette upgrade rend
XSLT enfin reellement utilisable.) Par exemple, Java est clairement
mieux adapte pour implementer certaines logiques que XSLT. L'inverse
est parfois vrai egalement. La solution : faire qu'il soit facile
d'utiliser Java lorsque c'est necessaire. Par exemple, on peut
toujours ecrire des processeurs specialises ou meme utiliser dans les
cas simples le Java Processor, qui compile automatiquement des
fichiers Java.
Avec une telle approche, il y a toujours le probleme de l'impedance
mismatch entre XML et Java. Mais ceci est un probleme commun a toutes
les applications qui combinent ces langages : faut-il Utiliser SAX ?
DOM ? dom4j ? JDOM ? XMLBeans ? Proposer toutes ces solutions ?
Probablement...
Ecrire des actions en XPL (qui a son tour peut utiliser XSLT ou Java,
par exemple) est une solution tres souple. Cocoon m'avait frustre il y
a longtemps avec ses actions, qui necessitaient Java, etaient tres mal
documentees, passaient des parametres par Hashtable (une solution a
"l'impedance mismatch" en question), et ne semblaient s'integrer que
maladroitement avec le langage de pipelines. (Je suis sur que je suis
en train d'insulter un peu la personne qui les a implementees, et je
m'en excuse d'avance). Ces actions sont-elles rendues obsoletes par
Cocoon Flow ?
Je mentionne ceci quand meme : c'est presque une surprise, mais dans
la plupart des projets sur lesquels nous avons travaille, l'approche
tout XML a fonctionne tres bien, et encore mieux depuis que nous
utilisons strictement XSLT 2.0 (draft...).
> Une des évolutions majeures de Cocoon 2.1 a été le flowscript,
> contrôleur d'enchainement des pages écrit en code tout ce qu'il y a
> de plus traditionnel. Et ça a été une révolution dans les domaines
> d'applications possibles.
> Au passage, le flowscript n'a rien à voir avec votre page flow, qui
> si j'ai bien compris s'apparente plutôt aux matchers de premier
> niveau dans une sitemap Cocoon. Cette proximité de nom pour des
> choses aussi différentes est certainement à l'origine de certains
> commentaires ascerbes sur la page de comparaison Orbeon/Cocoon.
On a effectivement les elements suivants :
o Declaration de pages selon modele, vue, actions, et formulaires
o Matching selon l'URL
o Mais aussi, et c'est l'aspect qui a ete oublie ci-dessus, en
fonction du resulat des actions, la determination de la page
suivante a executer. C'est donc plus une approche type FSM que celle
(quasi revolutionnaire, on peut bien l'avouer) de Cocoon basee sur
JavaScript et continuations, mais il est legitime de parler de Page
Flow. Le mecanisme supporte en plus XForms, et permet, a l'aide de
fragments de code XUpdate, de passer des parametres quelconques de
page en page par le biais de XForms. Je pretends que c'est tres
elegant ;-)
L'idee centrale est d'externaliser de controle du flow des pages de
sortes que les pages elles-memes soit completement independantes les
unes des autres. Toujours la fameuse "separation of concerns".
> Je vais aussi aller fouiller dans le source, parce que la
> comparaison avec Cocoon mentionne des pipelines SAX pour les deux
> produits, et je me demande bien comment on peut faire des requêtes
> XPath sur la sortie d'un processor pour choisir celui qui vient
> derrière lorsqu'on est en streaming d'événements SAX.
Les processeurs sont connectes ensemble a l'avance, sauf dans le cas
du p:choose et du p:for-each de XPL. Evidemment, il faut faire du
buffering, voire generer un DOM pour appliquer des expressions XPath
quelconques sur un stream SAX. Il y a un debut d'optimisation dans
XPathContentHandler, qui dans le futur va permettre d'appliquer des
expressions XPath simples sur un stream SAX sans requerir la creation
d'un DOM. Il y a encore du travail d'optimisation de ce cote-la, en
particulier parce que l'epilogue utilise plusieurs p:choose par
defaut. Mais notez que tous les processeurs XSLT interrompent le
stream SAX egalement, et c'est bien sur le cas dans Cocoon egalement.
-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:01:46 2004
