Mailing-List: contact users-fr-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users-fr@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <BAYC1-PASMTP028405F20F9406F04A04BCAB4B0@cez.ice>
Message-ID: <423CA031.7000902@sympatico.ca>
Date: Sat, 19 Mar 2005 15:57:05 -0600
From: =?ISO-8859-1?Q?S=E9bastien_ARBOGAST?= <argogast@sympatico.ca>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: users-fr@cocoon.apache.org
Subject: Re: Question =?ISO-8859-1?Q?strat=E9gique=2E=2E=2E?=
References: <BAYC1-PASMTP02188DD6F40EB1327CE882AB4B0@cez.ice>
 <423C6E9A.4050505@apache.org>
In-Reply-To: <423C6E9A.4050505@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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