cocoon-users-fr mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Question stratégique...
Date Sat, 19 Mar 2005 18:25:30 GMT
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


---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org


Mime
View raw message