Sébastien ARBOGAST wrote:
Bonjour,
Après avoir parcouru l'ensemble du User Guide de Cocoon, une question
me turlupine quant aux choix technologiques qui sont faits dans le
cadre du développement de Cocoon. Comme je l'ai déjà dit avant de
tester Cocoon je me suis attardé sur Orbeon Presentation Server, un
autre serveur de publication XML beaucoup moins puissant que Cocoon
mais qui se targue, en bon membre du W3C qu'ils sont, d'intégrer au
maximum les standards de cet organisme. Par exemple pour les
formulaires ils implémentent une partie des XForms.
Ma question est : qu'est-ce qui a motivé l'équipe de développement de
Cocoon à créer des nouvelles spécifications là où certaines technos
déjà existantes (et potentiellement répandues) auraient permis de
faire peu ou prou la même chose tout en diminuant le temps
d'apprentissage et en augmentant sa rentabilité ? Pour avoir
privilégié le XSP sur le JSP ? Pourquoi les CForms au lieu des XForms
? Si encore ces technos avaient une chance de devenir des standards de
facto en dehors de Cocoon, mais j'ai l'impression que les chances sont
plutôt limitées.
Attention je ne critique absolument pas les choix qui ont été faits et
je salue humblement ce travail titanesque que j'ai d'ailleurs la ferme
intention d'utiliser pour mon projet en définitive. Mais j'aimerais
juste comprendre les motivations c'est tout.
No problem, c'est une question fréquente à laquelle je réponds biens
volontiers.
A travers tes questions, on voit clairement apparaitre l'endroit où se
place Cocoon dans l'éventail des technologies. D'un côté XForms et le
monde XML/W3C, et de l'autre JSP avec le monde J2EE. Et puis aussi les
attentes et besoins de la communauté des développeurs qui sont les
premiers utilisateurs de Cocoon, et tous dans le cadre de leur activité
professionnelle (cf mon mail précédent sur l'influence des licenses sur
la nature des communautés).
Commençons donc par XForms. Tu soulignes que Orbeon implémente "une
partie" de XForms. Cette précision est essentielle. Il y a 2 ans, il y
avait un composant dans Cocoon nommé XMLForm. Il implémentait "une
partie" de XForms. Gros succès : XForms était le futur standard W3C des
formulaires en XML, et comme XML est la base de Cocoon, ça collait très
bien. Mais rapidement, on a rencontré des limites importantes liées au
fait que XForms, à travers ses mécanismes d'événements, est vraiment une
spécification pour le navigateur, et non pour le serveur. Faire une
implémentation serveur de XForms est compliqué. Certains l'ont fait
(Chiba par exemple), mais c'est lourd, et pas forcément réellement
utilisable dans le cadre d'une application qui doit répondre vite.
Partant de ce constat, des développeurs [1] ont décidé de développer un
autre framework de gestion de formulaires pour Cocoon, côté serveur
celui-là, apportant les fonctions réellement nécessaires au projets
qu'ils étaient en train de réaliser. Internationalisation de la saisie
(pas facile de décrire ça dans un XMLSchema utilisé par XForms),
validation avancée (intra-formulaire comme le permet XForms, mais aussi
en relation avec d'autres données applicatives), mise en forme évoluée
séparée de la définition du formulaire, etc. Cocoon Forms était né,
résultat d'une approche pragmatique par rapport à un besoin industriel
immédiat. Le succès qu'il rencontre dans Cocoon aujourd'hui montre que
ce choix "rebelle" par rapport à la spec n'est pas idiot.
Maintenant, si XForms prend réellement son essor, il sera tout à fait
envisageable de combiner XForms sur le client et Cocoon Forms sur le
serveur pour tirer le meilleur des 2. Cela a déjà été évoqué sur la
liste de développement.
JSP maintenant. Dans Cocoon, la "vue" du modèle MVC est le pipeline, qui
est une chaîne de traitement XML. Pour des raisons d'efficacité, cette
chaîne véhicule des événements SAX. Une JSP n'est rien d'autre qu'un
servlet compilé à la volée et, comme tout servlet, produit un flux
binaire dans un OutputStream. Ce flux peut être du texte représentant du
XML bien formé, mais ça reste un flux binaire. Pour l'utiliser dans un
pipeline, il faut le passer dans un parser XML, ce qui est moins
efficace que la production directe d'événements SAX. C'est pour cela
qu'est apparu XSP : ce sont des pages serveurs compilées à la volée,
comme JSP, mais qui sont des générateurs Cocoon, et donc produisent
directement des événements SAX.
Mais voilà, des utilisateurs de Cocoon ont aussi de l'existant en JSP.
C'est pourquoi on trouve aussi dans Cocoon un JSPGenerator, qui utilise
un parser comme décrit précédemment, mais qui permet d'être "J2EE
compliant" ou d'adapter un existant à moindre frais.
Tout ça pour dire que Cocoon se trouve à l'articulation des mondes XML
et J2EE, sans être obnubilé par le respect des standards. Si le standard
existe et est réellement utilisable, il n'y a pas de raison d'inventer
autre chose, sinon on construit une solution pragmatique s'appuyant sur
ces 2 mondes en respectant les principes fondamentaux de Cocoon qui sont
la séparation des domaines techniques et l'architecture en composants.
C'est d'ailleurs cette architecture extrèmement modulaire qui a permis
l'émergence de toutes les fonctions qu'on y trouve, des plus sérieuses
jusqu'à des choses un peu anecdotiques mais réellement surprenantes :
combien de frameworks de développement d'applications sont capable de
faire du traitement de partitions musicales en XSLT ?
Voilà qui je l'espère éclairera ta lanterne. Cocoon n'est pas toujours
"standard", mais lorsqu'il ne l'est pas, c'est parce que le standard
n'est pas vraiment la bonne solution :-)
Sylvain
[1] les gens d'Outerthought (http://outerthought.org). Il sont 3, tous
committers Cocoon!
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
|
