cocoon-users-fr mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien ARBOGAST <argog...@sympatico.ca>
Subject Re: Question stratégique...
Date Sat, 19 Mar 2005 21:57:05 GMT
Merci Sylvain pour cette réponse on ne peut plus complète. Je suis 
d'accord sur toute la ligne. J'ai tout compris ;-) . En plus en faisant 
quelques recherches sur Chiba je suis tombé sur un sous-projet nommé 
Chicoon dont le but est d'intégrer Chiba dans Cocoon. Donc même si ce 
n'est pas forcément la meilleure solution, voilà qui devrait encore 
étendre les choix technologiques possibles.

Sébastien

Sylvain Wallez a écrit :

> 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!
>

---------------------------------------------------------------------
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