On Sun, 2004-09-26 at 04:01, Erik Bruchez wrote:
> Sylvain Wallez wrote:
> > 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.)
<digression>
C'est un peu hors sujet puisque Presentation Server n'est pas lié à XSLT
2.0, mais je dois dire que je ne partage pas cet enthousiasme vis à vis
de XSLT 2.0 et ce pour deux raisons.
La première est d'ordre presque dogmatique : je pense que la décision
d'appuyer XSLT 2.0 sur le PSVI est une erreur architecturale majeure
(j'ai eu l'occasion d'expliquer cela sur plusieurs forums) et, bien que
XSLT 2.0 comprenne des nouvelles fonctionnalités qui manquent
cruellement à XSLT 1.0, j'ai tendance dans la mesure du possible à
"boycotter" XSLT 2.0 pour ne pas contribuer à son succès et d'éviter de
l'utiliser pour des raisons somme toute assez similaires à celles pour
lesquelles j'évite d'acheter des produits contenant des OGM :-) ...
La seconde est d'ordre très pragmatique : j'ai trop apprécié que les
processeurs XSLT 1.0 soient devenus interchangeables pour vouloir
utiliser un langage dans lequel il n'y ait qu'une seule implémentation,
quelque soit la qualité de cette implémentation.
Aujourd'hui, XSLT 2.0 n'est clairement pas portable et je ne vois pas
beaucoup d'indications que cela change dans un avenir proche.
Pour ces deux raisons, je préférerais rester en XSLT 1.0, quitte à
utiliser EXSLT (qui est aujourd'hui plus "portable" que XSALT 2.0) et à
implémenter en Java les extensions ou fonctions dont l'absence
pourraient me bloquer.
</digression>
> 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.
Cela me semble clair et je ne pense pas que la communauté Cocoon y
trouvent quoique ce soit à redire.
> 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 n'ai encore regardé de près ni le flowscript Cocoon ni les page-flows
Presentation Server, mais je me demande dans quelle mesure ils sont
conformes ou contraires à l'architecture REST et permettraient
d'implémenter des systèmes comme ceux décrits par Paul Prescod dans
http://www.prescod.net/rest/state_transition.html.
Le mécanisme de recherche tel que je l'ai implémenté dans mon prototype
est un bon exemple de la deuxième approche (A Stateless Example)
présenté par Paul et cela convient parfaitement à ce type d'application.
Pour des choses plus complexes (par exemple la gestion des abonnements
sur les listes de discussions), j'aimerais essayer la première approche
(A State-shifting Example) dans laquelle les informations envoyées par
le client sont publiées sur le serveur comme on le ferait pour un
document.
L'application Web se rapproche alors de la logique d'un site Web
classique (comme XMLfr) dans la mesure où il ne s'agit "que" de
présenter des documents publiés sur un serveur.
C'est peut-être relativement voisin de ce qui se passe avec le
flowscript Cocoon ou les page-flows Presentation Server, le point
important étant que pour être conforme à l'architecture REST, l'état ne
doit pas être quelque chose d'opaque caché par le framework mais une
ressource publiée sur le serveur au même titre que les autres ressources
(un article par exemple).
Eric
--
Tired of typing XML tags?
http://wikiml.org
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
--
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 11:10:44 2004
