Nous nous sommes interrogés sur les résultats de l’équipe JSF, nous les avons comparés à nos expériences précédentes (implémentations IBM, Oracle, RI et MyFaces). Nous nous souvenions des différents flags de debug aussi bien dans les implémentations que dans les frameworks comme Facelets.

Finalement, lorsque la JSR 314 : JSF 2 porte explicitement des objectifs comme « Vastly improve the developer experience with regard to error messages … », nous nous disons que nous ne sommes pas les seuls à être passés à côté de la plaque

Par ailleurs, nous avons été très positivement impressionnés par la présentation JSF 2.0: Insight and Opinion d’Ed Burns, spec lead JSF 2, à JavaOne 2008. Il montrait une écoute attentive des remarques et reproches faits à JSF 1.

L’état d’esprit de l’expert group JSF 2 nous parait très prometteur et nous laisse rêver que JSF 2 sera à JSF 1 ce que EJB3&JPA ont été à EJB 2.

Cyrille (Xebia)

merci

Guillaume (Xebia)

Faute de temps et d’équipes disponible, nous n’avons, à regret, pas pu tester JBoss Seam mais voici quelques observations sur ce sujet qui me laisse penser que Seam est un des framework Web les plus structurant et les plus impactant pour une DSI :

Seam est très structurant : Seam fournit un modèle de programmation unifié liant JSF et EJB3[1]. Le travail de JBoss pallie à un manque des standards Java EE, il est de grande qualité et très innovant, il inspirera très certainement JSR-299 Web Beans (dont Gavin King est spec leader) et JSF 2.0 mais c’est pour le moment une initiative propriétaire et pas un standard.

Seam est beaucoup plus vaste que JSF : en plus d’être le liant entre JSF en EJB3, Seam étend JSF et apporte de nombreuse fonctionnalités (conversations, intégration de jBPM, etc).

JBoss est en train de constituer une stack web complète : grâce à son partenariat avec Exadel, JBoss constitue une stack composée de Seam, RichFaces, ajax4jsf et RedHat Developer Studio (RHDS). Cette approche unifiée a déjà prouvé qu’elle apporte beaucoup de valeur mais c’est un choix beaucoup plus structurant pour une DSI que celui d’un framework de présentation.

Cette stack peut être difficile à intégrer aux autre éléments structurant d’un client. Par example, EJB3, certes optionnel mais très important dans Seam, n’est pas encore disponible sur Websphere. De même, RedHat Developer Studio est une alternative à Rational Application Developer ou BEA Workshop (via des plugins) plutôt que de s’intégrer à eux (via des plugins Eclipse) [2]. A l’inverse, le framework de présentation Spring MVC propose SpringIDE qui est agnostique du serveur d’application et s’intègre à tout IDE reposant sur Eclipse 3.1+ (IBM RAD, BEA Workshop, etc).

Enfin, Seam, par son fort ancrage dans la stack JBoss, est un choix politique [3] : depuis sa création par le sulfureux Marc Fleury, JBoss a eu une place légèrement à l’écart dans l’écho système Java. Cela n’est pas lié à ses produits (JBoss app server, Hibernate, Seam, JBoss Rule) dont la qualité est unanimement reconnue mais probablement plus aux déclarations tonitruantes des premières années. L’impact est important car il ne faut pas s’attendre à un partenariat entre JBoss et les grands éditeurs Java EE comme Spring/Interface21 l’a fait avec BEA et IBM.

Il en résulte qu’avoir une stratégie JBoss ne s’intègre pas à une stratégie sur un serveur Java EE autre que JBoss, ce sera plus une coexistence pacifique des deux stratégies. A l’inverse, il est tout à fait possible d’avoir une stratégie BEA+Spring ou Websphere+Spring.

Pour conclure, JBoss Seam est un framework très intéressant mais dont le choix dépasse largement celui d’un simple framework de présentation et impacte rapidement la stratégie du socle de développement complet.

Cyrille (Xebia)

[1] Extraits de la doc JBoss Seam : « Seam unifies the component models of JSF and EJB3″, « Seam provides a uniform component model »
[2] Extrait de la doc RHDS : « Red Hat Developer Studio is a set of eclipse-based development tools that are pre-configured for JBoss Enterprise Middleware Platforms »
[3] Cette dimension politique s’applique beaucoup moins à Hibernate qui a gagné la confiance de ses utilisateurs avant d’être intégré à JBoss et qui en es resté très indépendant. On notera quand même concernant Hibernate que les grands acteurs comme BEA, IBM ou Interface21/Spring préfèrent jouer la carte d’OpenJPA plutôt que celle d’Hibernate.

Tout d’abord, nous sommes désolés pour le retard dans les réponses aux commentaires.

Ensuite, pour revenir sur le choix de JSF, bien que j’ai fait partie de l’équipe Struts2, voici comment nous avons voulu tester JSF :
- En tant que 100% standard Java et nous avons par conséquent exclu les frameworks de haut niveau comme Seam ou Facelets qui nous semblaient apporter beaucoup trop de choses à JSF pour que le développement soit toujours qualifiable de 100% pur JSF
- En reprenant les exigences classiques en informatique (pérennité de 5-10 ans et documentation minimum) de gestion et nous n’avons pas eu le temps d’identifier une librairie de composants graphiques riches qui nous fasse confiance :
–> Les projets Apache Tomahawk, Tobago et Trinidad sont redondants,
peu documentés (j’ai personnellement souffert de tomahawk sur un prototype) et sans roadmap de convergence ; en tout cas, nous ne l’avons pas trouvé en explorant le web.
–> Icefaces : je ne connaissais pas, merci. Le site Web est riche, le contrat de licence très clair et l’outillage dans les IDE bien avancé. Cependant, la question de la pérennité me semble importante. Quelle est la viabilité d’Icefaces Technologies dès lors que leur unique produit devient Open Source ? Que se passera-t-il si Icefaces Technologies se retire de ce projet open source (faillite, changement de stratégie, etc) ?
–> Nous n’avons pas vu d’autre librairie de composants graphiques riches.

Voici les raisons qui nous ont amené à évaluer JSF seul. Nous aurions aimé renforcer JSF d’une librairie graphique complémentaire mais, peut être par faute de temps, nous n’avons pas trouvé de candidat qui satisfasse nos critères.

Et une remarque quand même : les autres frameworks Web n’ont pas posé autant de débats sur leur ‘habillage’ en compléments divers et variés.

Le choix de JSF est sensiblement plus complexe que l’implémentation JSF seule (JSF-RI, MyFaces, JSF du serveur d’application, etc), il faut aussi choisir les librairies additionnelles [1].

Cyrille (Xebia)

[1] Nous avons fait un reproche du même ordre à Struts2 sur la variété des méthodes de configuration (struts.xml, via spring, struts-annotation, struts-zero-config, etc)

PS:J’ajoute que pour la partie Workfow du concours Seam intégre jBPM, bon c’est un peu osé sur un developpement d’une journée mais bon…

C’est un peu biaisé du coup, le fait que ce soit cette équipe qui gagne, non ?
Le fait que les autres équipes aient pris des technologies qu’elles ne maitrisaient pas joue forcément contre elles !

En dehors de cela, je trouve que la façon d’aborder la comparaison est intéressante et ludique !

Vous dites :
« …Dès le début JSF présente la spécificité d’utiliser un buffer spécifique pour écrire la response. »

Pourriez-vous me préciser le rôle ou le nom de ce buffer spécifique, parceque je n’en ai jamais entendu parlé?

j’ai d’autres griefs contre la partie JSF que je te trouve un peu légère…mais faute de temps…

Medo.

JBoss Seam aurait pû être un candidat possible pour votre évaluation. Il propose de souder une architecture EJB3 et JSF sans douleur. Le problème de JSF est qu’il y a trop de XML à configurer. Seam via des annotations simplifie beaucoup l’écriture du code. Par ailleurs il ajoute la notion de conversation, dispose d’un support d’AJAX et plus globalement des composants distants. Et enfin il propose soit d’intégrer MyFaces (qui est en perte de vitesse) soit IceFaces (très bonne librairie). Le tout rapidement et sans soucis.

Si vous avez encore votre cahier des charges quelque part, je me lancerai bien dans une implémentation avec Seam afin de vous montrer quelques unes de ses possibilités. Ou peut-être avez-vous une url de la version Struts2 ?

Conclusion :
- assez fortement couplé à JEE (avec les plus et les moins : JPA est très bien pris en charge, Spring pas forcément (il parait que ca s’améliore) ;
- ca reste du JSF (c’est un défaut en soit , mais ca semble une bonne façon d’en faire de manière un peu moins fastidieuse ;
- pas forcément une solution pertinente en terme de « framework web » si l’on cherche juste un outils pour la présentation, plus pour un framework « full stack », sur un projet sans existant ;

A valider, ce ne sont que des retours externes.

Avez-vous des retours sur Seam de JBoss?

Merci.

Seb.

Et bien ce dernier choix n’est pas forcément pertinent : il existe un framework composants/évènements *simple* et performant : Tapestry 5 – le 5 est important : http://tapestry.apache.org/tapestry5/ Bon, comme vous l’aurait compris, je suis conquis.

En fait, j’avais fait une étude comparative des frameworks Java web au début de l’année pour le projet sur lequel je travaille : http://interldap.org.
Ma première sélection était arrivée à la même que vous, Tapestry 5 en plus. Une première étude rapide avait fait ressortir Wicket (1.3) et Tapestry 5 (5.0.2), pour lesquelles une étude plus poussée (une semaine) a pu être mené. Bilan : le premier était devant au niveau « gestion de la communauté/des versions », le second avait gagné haut la main au niveau technique.
Bref, Wicket est vraiment intéressant, mais Tapestry 5 est tout simplement mieux (bon, en plus, je suis plus développeur Web que Swing, ca aide pas ^^)

Allez, je me prête au jeu des points forts / points faibles :
Points forts :
- expérience du leader du projet. Howard L. Ship développe Tapestry depuis 7 ans, cette version est un refonte complète dons laquelle il a mis toute son expérience – et il n’est pas trop mauvais, comme développeur… Tout le reste en découle. Pour rappel, Tapestry est un projet apache depuis 4 ans, et de top niveau depuis presque 2 ans.
- simplicité : les composants sont des POJO, T5 utilise Maven (créer un nouveau projet se résume à une (longue) ligne commande), les principes de conventions over configuration de rails sont repris (il n’y qu’un seul fichier de config : le web.xml), bref on retrouve très vite ses petits ;
- séparation présentation/logique : chaque page ou composant est classe + un template, le template est du xhtml valide (du bonheur pour les designers) ;
- testabilité : encore les pojos, et le test unitaire et d’intégration est une obsession des devs de Tapestry, ils ont développé des outils efficaces, qu’on peut utiliser.
- développement itératif : c’est un vrai bonheur ! Pas de recompilation/déploiement : on modifie un composant (le java ou le template), on recharge la page dans le navigateur, c’est tout ;
- composants surpuissant : la bibliothèque standard contient déjà un « bean editor » qui permet de faire du CRUD en quelques lignes, et une « Grid » qui fait de la pagination sur des liste d’objet comme une grande. Et créer de nouveau composant est on ne peut plus simple…
- monté en charge : après le test, c’est un peu l’autre manie de Howard. Tapestry est designé pour monté en charge : les pages sont mises en cache, les frameword est pensé pour pouvoir être répliqué sur des clusters, etc ;
- séparation des structures internes et des API exposées : afin de pouvoir notablement changer le framework, sans que ses utilisateurs en patissent (trop).
- Inversion de contrôle très puissante : c’est guice qui aurait été tuné pour le développement Web. Et l’intégration avec Spring est excellente.
- full Java 5. J’ai un doute sur « point fort » : c’est clairement un avantage en terme de développement, mais ça impose un JVM 5. Bon, je suis dev, alors c’est un point fort

Points négatifs :
- Tapestry 5 n’est pas encore sorti officiellement, on en est à la 6ième « alpha ». Et pour l’instant, les montées en version se sont fait plutôt sans douleur.
- documentation faiblarde : elle s’améliore, en particulier grâce aux « how to » disponible sur le wiki, mais pour l’instant, elle reste légère.
- pas (encore) d’Ajax. C’est *la* grosse fonctionnalité manquante. Elle sera le centre des attentions de la prochaine alpha (qui devrait d’ailleurs être la première béta), mais pour l’instant, l’Ajax, c’est à la main.
- petitesse de la communauté. Tapestry à une histoire difficile, avec des changements de versions majeures complètement incompatibles, d’où un communauté séparée entre des utilisateurs des versions 3, 4 et 5. La version 5 devrait résoudre se problème, mais pour l’existant, le mal est fait.
- écosystème très peu développé : peu de projets connexes, de composant, de tutoriaux, etc. C’est encore une alpha, ca se sent, même s’il commence à y avoir une certaine émulsion.

Bref, j’utilise maintenant Tapestry 5 depuis quelques mois, et je ne peux imaginer revenir en arrière, sur un framework MVC standard, (j’ai fait du Struts, Strints 2, Spring MVC…) ou sur du JSF (mais comment fait Sun pour se planter à chaque fois dans ses framework web ? (oui oui, c’est un raccourcis)). Aujourd’hui, le fait de devoir redéployer pour tester me parait une barrière énorme pour le développement web (je comprend les adorateurs de langage des scripts pour cela).

Bon, j’ai été un peu long, mais vraiment, d’autant plus que je n’arrete pas de trouvre des fonctionnalité oubliées, mais ce framework est *bluffant*. Aujourd’hui, seul Lift ( http://liftweb.net/ ) me parait plus prometteur, mais c’est pour du plus long terme.

Bref, essayez-le, votre vision du développement Web en Java va changer