Sébastien Geindre wrote:
bjr à tous,
Je ne souhaite en aucun cas lancer un troll sur anyware et
coocon...Sylvain et Anyware ont apporté tellement à la communauté
cocoon qu'il serait stupide de jeter la pierre à quiconque.
Par contre, j'aimerais bien connaître les raisons qui ont poussé
Anyware a délaissé Cocoon et à investir dans d'autres framework web
(Wicket,...)
D'ou le sujet...
Vaste sujet !
Anyware Technologies n'a pas vraiment délaissé Cocoon, mais a évolué
d'une mono-culture cocoonesque à la reconnaissance qu'à différents
besoins correspondent différents outils, encouragé dans cette voie par
l'évolution de la technologie, aussi bien côté browser que côté frameworks.
Concrètement, Anyware utilise Cocoon là où son utilisation est
justifiée, c'est à dire dans les applications de type CMS et chaînes de
publication documentaires, là où on a besoin de pipelines de
transformations. Cocoon est encore sans équivalent dans ce domaine (à
part Orbeon).
Dans le domaine des applications web (gros formulaires, écrans très
interactifs avec Ajax) auquel Cocoon s'était attaqué et où j'avais
personnellement été très actif, Cocoon a pu être précurseur et novateur,
mais il a été rapidement dépassé par des nouveaux venus dédiés à ce
domaine tels que Wicket ou GWT, mais aussi des approches plus
client-side comme DWR où la composante serveur est purement applicative.
Ces nouveaux arrivants dans les applications web, en poussant la barre
du côté tout en Java/Javascript là où Cocoon était un max en XML ont
aussi apporté de l'air frais à une époque ou nombreux étaient ceux qui
avaient une saturation des crochet ouvrant, crochet fermant. La
programmation déclarative a ses limites.
Au final, le constat a été qu'utiliser Cocoon dans des applications
constituées essentiellement de formulaires n'avait pas vraiment de sens,
et que les nouveaux frameworks spécialisés dans ce domaine apportaient
plus de productivité. Wicket est de ceux-là, et nous l'avons utilisé
avec succès et satisfaction pour ce type d'application.
En conclusion, il n'y a pas d'outil magique, et il ne faut pas essayer
de vouloir tout faire avec Cocoon. Il a par contre ses domaines
d'application privilégiés, qui sans hasard correspondent à sa mission
initiale : les chaînes de transformations XML, très adaptées pour les
applications de type CMS. Anyware a d'ailleurs une grosse activité CMS
utilisant le produit maison Ametys bâti sur Cocoon, qui a été mis en
opensource [1].
D'un point de vue plus personnel, j'ai aussi évolué en prenant il y a 2
ans d'importantes responsabilités dans le projet Joost [2] où Cocoon
n'avait pas vraiment sa place. Ce changement coïncidant avec une
saturation du tout XML et des gros framework, revenir à du tout-Java
avec des servlets (presque) de base en frontal de grosse logique métier,
et utiliser Wicket sur des applications de type back-office a été un
renouvellement presque salutaire.
Dans l'étape suivante se mon évolution professionnelle (teasing teasing,
à suivre sur mon blog dans les prochaines semaines), je vais à nouveau
avoir besoin de transformations XML. Mais je ne crois pas que je
reviendrai à Cocoon, au moins sous sa forme actuelle. J'ai besoin de
quelque chose de plus léger, plus agile, qu'on puisse utiliser
directement depuis Java ou Javascript côté serveur. C'est une tendance
qu'on sent depuis longtemps au sein du groupe des développeurs de
Cocoon, et il est possible qu'un mini-Cocoon apparaisse dans le futur.
Au final, la conclusion est que Cocoon est un produit mature et éprouvé,
très adapté à certains problèmes, mais pas à tous.
Voilà. Merci à ceux qui ont lu jusqu'ici, j'espère que ça clarifie les
choses.
Sylvain
[1] http://www.ametys.org/
[2] http://bluxte.net/blog/2006-11/15-28-34.html
--
Sylvain Wallez - http://bluxte.net
-
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:[EMAIL PROTECTED]
Autres commandes : mailto:[EMAIL PROTECTED]
