Xebia Web Framework Contest
Pour tous les consultants de Xebia France, le dernier vendredi de chaque mois est important : c’est le jour du XKE, le Xebia Knowledge Exchange. L’ensemble des consultants est rassemblé pour échanger durant une journée entière sur tous les sujets liés à l’écosystème Java / J2EE ainsi que les méthodes agiles. D’habitude la journée est découpée en plusieurs sessions allant de 45 mn à 3 h, suivant les sujets et le mode d’interaction (de la présentation formelle à des travaux pratiques sur des sujets complexes).
Le mois dernier, nous avons décidé de faire du XKE le Xebia Web Framework Contest, un concours de développement autour des framework de présentation.
4 équipes ont développé la même application web, chacune avec un framework (très) différent. Les frameworks retenus étaient :
- Strut2,
- Google Web ToolKit,
- Wicket,
- My Faces (JSF).
8h30 certains, les plus scolaires, sont déjà arrivés et aiguisent leurs environnements, se concertent sur les rôles de chacun.
9h00 tout le monde est là, certains prennent leur café en discutant de tout sauf du concours qui les attend alors que d’autres sont fin prêts …
9h30 les spécifications, tenues secrètes jusqu’au jour J sont enfin distribuées aux équipes et là : grande surprise et grande rigolade ….
Wanda Zeller, directrice d’un réseau de call girls international, a décidé d’augmenter son volume d’affaire en mettant en ligne un site de réservation interactif de ses protégées. Mme Zeller, que son activité contraint à la discrétion, a délégué son chargé d’affaires, M. Moussaud, de relayer ses exigences et de piloter les développements. Mme Zeller, qui vit avec son temps, dispose d’ores et déjà d’un système de réservation qu’utilisent les opérateurs de son call-center marocain. Afin de limiter les efforts de développement, il a été décidé de réutiliser les services métier mis au point pour ce système de réservation, et de limiter les développements à la couche de présentation.
Les spécifications de nouveaux lots seront ensuite distribuées à un rythme assez soutenu, à raison d’une toutes les heures trente. Chacune ayant pour but d’adresser un pan particulier.
- Le premier lot mettait en place les mécanismes de recherche simple et un système de panier avec commande.
- Le lot 2 apportait la couche « sécurité » sur les commandes.
- Le lot 3 ajoutait la mise en place d’un workflow de validation des commandes.
- Enfin le dernier lot mettait l’accent sur l’aspect validation.
Après une journée intense de développement, chaque équipe est venue présenter son œuvre et donner son avis sur les avantages et inconvénients de la solution étudiée.
Google Web Toolkit
L’équipe a bataillé un moment pour trouver quels fichiers étaient à synchroniser entre les membres de l’équipe et ceux qui ne l’étaient pas. Pour ne pas perdre de temps (c’était quand même un concours !), la synchronisation s’est faite finallement par clé USB !
Ce qui avait séduit l’équipe avec ce framework nouvelle génération est le concept du ‘Tout-Java’: le client et le serveur sont codés en java, GWT se charge de la génération des pages web et du javascript. Mais ce modèle à des contraintes:
- Implémentation d’une interface IsSerialisable pour tout objet qui transite entre le client et le serveur (réglé depuis la version 1.4).
- Support de Java 1.4 (seulement), donc il faut oublier les génériques et les annotations pour la partie client (fonctionnalité programmé pour la future version 1.5 ).
- Le concept client-serveur reste quand même assez déroutant quand depuis des années on manipule chaque jours des objets de type Request/Response, des pages JSP/Html ou des actions ‘Struts’.
La conclusion de l’équipe est qu’il faut vraiment aborder GWT comme un framework Client Riche avec un concept de client/serveur; les outils se chargeant entièrement de l’exposition en mode Web (JSP/CSS/AJax). Le coût d’entrée semble assez important et les composants graphiques limités (il n’est pas évident d’intégrer des composants d’une maquette HTML existante). Donc GWT est un outil à suivre en attendant la maturité.
Synthèse de l’équipe :
Les bons points :
- Gestion transparente des différents browsers.
- Possibilité d’utiliser un debugger Java (celui de l’environnement de développement choisi, Eclipse par exemple).
- Beaucoup de buzz autour du projet. Notamment concernant les extensions graphiques (portage de plusieurs librairies AJAX), début d’intégration avec Spring.
- Un retour à la programmation graphique par composant.
- Facile de mettre en place une IHM simple.
Les mauvais points :
- Seule une partie du JRE est supportée côté client et pour les DTO utilisés par les RCPs (ex: pas toutes les collections).
- Besoin d’un mapping objet métier/DTO utilisés par GWT (Serializable et un constructeur public par défaut).
- Manque guide de bonnes pratiques et de la documentation en général.
- Les API ne sont pas toutes détaillées.
- Il n’y a que des composants graphiques « simples ». Si l’on veut utiliser des composants plus évolués, il faut soit les coder ou bien se tourner vers des librairies de widgets GWT Open Source « non Google ».
Les points non abordés :
- Possibilité de faire des tests unitaires.
- Internationalisation.
- JavaScript Native Interface (JSNI).
- Exposition de services via Web Services/JSON/XML.
- Facilité/difficulté du respect d’une charte graphique.
- Authentification.
- Respect des standards, facilité de référencement.
- Intégration à l’IDE Idea (semble assez poussée, gestion des CSS et modules à partir du code Java).
Struts 2
L’équipe avait préparé un template de projet Struts2 avant le XKE, projet Eclipse/Maven 2, web.xml déjà configuré, librairies installées, et différents tests « Hello World » de plugins (zero conf, etc…).
Résultat : c’est l’équipe gagnante.
L’équipe n’a pas rencontré de difficultés particulières, et a décidé de développer l’application avec ses tests unitaires, ce qui n’était peut être pas nécessaire dans le cadre du concours, mais qui a permis de démontrer la facilité avec laquelle les actions Struts2 peuvent être testées unitairement (le gros défaut de Struts 1).
Synthèse de l’équipe :
Les bons points :
- Testabilité : écrire des tests unitaires pour les actions, qui sont de simples POJOs, est très simple.
- Modularité des filtres sur les actions : les piles d’Interceptors sont très pratiques pour appliquer des filtres différents aux actions (authentification etc.). Mais est-ce réellement si utile ? A part le classique interceptor d’authentification qui ne s’applique pas aux actions de type « login » et « forgotten password », a-t-on vraiment besoin de tant de modularité sur les filtres ?
- Simplicité : Struts 2 est simple à utiliser par une équipe projet. Sa modularité et sa testabilité le rendent parfaitement adapté au travail en équipe.
- Prédictibilité par son efficacité et son classicisme : Struts2 est un framework éprouvé aux concepts très répandus ( »Action based », Orienté Objet simple) qui ne causera pas de mauvaise surprise. Struts 2 sera prédictible sur un projet.
- Elégance des interactions HTTP : URL claires et un modèle post-and-redirect fiable (double submit) et efficace (bookmarkable) malgré WW-1714 qui est en cours de résolution.
- Souplesse de l’interface graphique : le mécanisme de template est très pratique mettre en œuvre la charte graphique d’un site ou d’une application. SiteMesh est un complément naturel très efficace.
- Débuggabilité : des tags de debug (facilement désactivables pour la production) et un browser de configuration simplifient le troubleshooting (voir également les mauvais points sur la débuggabilité de Struts2).
- Coût d’entrée réduit : le framework est plus simple à appréhender que Struts 1.
- Form beans : aucun fichier de configuration, on peut passer de simples POJO à la vue Tests unitaires : les actions sont testables facilement avec JUnit, les actions sont des POJO.
- Templates : intégration avec Sitemesh aisée pour les templates, les templates Sitemesh ont accès aux tags Struts grâce au plugin struts2-sitemesh.
- Ajax : tags Ajax (support Ajax basé sur le toolkit Dojo) simplifient, voir masquent, l’utilisation de dojoSpring: support de Spring, on choisit le framework d’injection à utiliser dans la configuration.
- Expression Language : les taglibs utilisent OGNL, plus puissant que JSTL, Communauté: framework MVC le plus téléchargé du moment (http://www.jroller.com/TedHusted/entry/struts_skyrockets ) , les mailing lists sont très actives.
Les mauvais points :
- Hétérogénéité / dispersion : Struts 2 se disperse en proposant souvent plusieurs solutions pour un sujet sans qu’aucune ne soit pleinement satisfaisante.
- Trois technos pour le HTML : JSP, Freemarker et Velocity.
- Plusieurs projets de configuration par annotations : Zero config etc.
- Configuration propriétaire (struts.xml).
- Spring est le standard de-facto pour configurer l’assemblage des composants d’une application. Il serait très pratique de pouvoir configurer Struts2 dans les fichiers Spring grâce au mécanisme d’extension de configuration introduit dans Spring 2 à l’instar de la configuration d’Apache CXF (e.g.
- Spring est le standard de-facto pour configurer l’assemblage des composants d’une application. Il serait très pratique de pouvoir configurer Struts2 dans les fichiers Spring grâce au mécanisme d’extension de configuration introduit dans Spring 2 à l’instar de la configuration d’Apache CXF (e.g.
- Productivité modérée : c’est probablement un écueil du classicisme et de la testabilité (découplage actions-pojo de la présentation) mais la productivité n’est pas stupéfiante.
- Debuggabilité : Struts2 n’affiche aucun message d’erreur en cas de coquille sur les variables de scripting (i.e. manipulées par OGNL) aussi bien dans les page web (jsp, ftl ou velocity) que dans la config (paramètres dans les redirections …). Le problème est en cours de résolution.
- Performances : l’application doit être configurée d’une certaine manière pour obtenir des performances acceptables (http://struts.apache.org/2.x/docs/performance-tuning.html). OGNL est plus lent que JSTL dans certains cas (mais est aussi plus riche).
- Développement : l’équipe de commiteurs est réduite, les trous de sécurité prennent du temps à être corrigés.
- Ajax : Le support Ajax est intégré dans le cœur de Struts2, pas sous forme de plugin, une mise à jour de dojo toolkit demande de sortir une nouvelle version de Struts2 (va changer dans Struts 2.1).
- Documentation : il est parfois difficile de se repérer dans la documentation, certaines pages font parfois référence à webwork, elle n’est pas tout le temps à jour (c’est bien évidemment lié au faible nombre de commiteurs sur le projet).
Conclusion :
Struts2 est basé sur l’excellent WebWork 2.2, les bases sont saines. En revanche, les nouveaux développements Struts 2.0 ont pris du temps, et certains ont été remis en cause dans le futur Struts 2.1. Struts 2.1 est plein de promesses, les performances devraient être meilleures (mise à jour vers OGNL 2.7, vers Dojo 0.9,…), et le plugin SmartURLs devrait permettre de se passer de la configuration explicite, pour se rapprocher encore du paradigme « Convention over Configuration ». Le projet tend vers une consolidation des différents plugins, et a appris de ses erreurs depuis la première release de Struts2. Aujourd’hui nous pouvons conseiller d’attendre la première release stable et éprouvée de Struts 2.1 (Struts 2.1.0 devrait sortir à la fin Octobre 2007) pour démarrer un nouveau projet. La branche 2.0 ne va plus évoluer, et le saut 2.0 vers 2.1 ne sera pas forcément transparent!
JSF/My Faces
Ce groupe de Travail a véritablement bataillé durant toute la journée et le bilan affiché en fin de journée est un peu mitigé.
Les bons points :
- Concepts proches des frameworks Struts 2 et Spring MVC
- Utilisation de POJO simple
- La tentative de standardisation
- Le support des éditeurs
Les mauvais points :
- Complexité de mise en oeuvre
- Manque de documentation
- Manque de transparence sur le fonctionnement du framework
- Impossibilité de mixer JSF avec d’autres composants (Tag JSP 2.0, Taglibs tierces, etc.)
Synthèse de l’équipe :
- Dès le début JSF présente la spécificité d’utiliser un buffer spécifique pour écrire la response.
- Il n’est pas possible d’utiliser directement du code HTML à l’intérieur de tags JSF ! Vous devez baliser tout vos blocs html par <f:verbatim> (bye bye xhtml) ou utiliser la tablig htmLib pour remplacer tous vos tags html par le tag
- Autre impact, plus gênant : l’intégration du code JSF avec les autres taglib. JSF ne dispose pas de certains tags intégrés de base dans d’autres frameworks. Par exemple, en JSF les conditions et les boucles n’existent pas. Et comme on atteint vite les limites des fonctionnalités offertes par les taglib JSF, on aimerait bien pouvoir retourner sur du JSTL ; mais là encore vous vous heurterez à des problèmes de compatibilité à cause du « buffer JSF » mentionné plus haut.
- La gestion des templates n’existant pas non plus dans JSF, il faut utiliser struts-tiles.
- Côté gestion des erreurs justement, on peut dire que JSF n’est pas bavard. Pour certains problèmes de navigation la page appelante est simplement réaffichée, sans aucun message d’erreur ! Autant dire que certains bugs deviennent très difficiles à analyser.
- Autre détail, le nom des tags dans les taglib ou même pour les fichiers de conf ne sont pas très intuitifs, mais si vous avez besoin, des plugins permettent de vous imprégner du vocabulaire JSF assez rapidement.
Conclusion :
JSF n’est clairement pas le framework le plus productif, en tous cas pas sur une journée car le coût d’entrée est lourd. Et même une fois habitué au framework, on peut se demander comment être productif sans remontée d’erreur et quelles limites posera cette gestion de buffer spécifique dans le cadre d’un vrai projet ?
Wicket
On peut considérer Wicket comme la bonne surprise de cette journée. Replaçons le contexte. Au moment des choix de chaque consultant, certains ont préféré partir sur la nouveauté (Wicket) par rapport à l’ancien solide et fiable (ex : Struts 2). Les différents contraintes de leur vie professionnelle n’ont pas permis aux membres de cette équipe d’affiner le sujet avant le jour J. Seul un rapide coup d’œil sur le « HelloWorld » de Wicket le soir précédant la compétition. C’est donc sans grandes connaissances qu’ils ont abordés ce concours. A la fin de la journée, ils avaient implémentés globalement l’ensemble du Lot 1 (Rappel: My Faces et GWT n’y sont pas arrivés !). C’est là que le framework choisit intervient.
Les bons points :
- Prise en main rapide
- Véritable séparation entre la partie cliente et la partie serveur (utilisation de plain HTML)
- Retour à la programmation graphique des composants
- Mécanismes de templating par héritage Java
- Pas de fichier de configuration : une classe définie dans le web.xml sert de point d’entrée
- Navigation entre les pages définies en Java (ex: new Link(PageSuivante.class))
- Démarrage rapide (notamment grâce à l’archetype Maven2)
Les mauvais points :
- Documentation très très succinte malgré l’existence d’exemples
- Pas d’explication des concepts de base (navigation, gestion de la session, templating, etc)
Les points non abordés :
- Possibilité de faire des tests unitaires
- Validation de formulaire
- Internationalisation
- Intégration de composant Ajax
Synthèse de l’équipe :
Les concepts de wicket sont les suivants :
- Séparation très claire entre la présentation (.html) et les actions métiers (.java).
- Pas de longue configuration xml, le seul fichier xml est le web.xml.
- Une création automatique d’un squelette d’application avec un seul artefact maven. (est-ce maven la réelle clé de la productivité ?)
- Haute réutilisation des maquettes html (fournie avec les spécifications) : le positionnement des éléments dynamiques utilisent principalement des balises HTML de type <span> avec un attribut « wicket.id ».
Conclusion :
En un mot, un framework web simple, facile et pragmatique. Ces 3 qualificatifs ont permis à l’équipe d’aller très vite une fois les concepts acquis. Ils ont cependant beaucoup « ralé » sur le manque de documentation. Seuls les exemples fournis leur ont permis de déjouer et de comprendre les subtilités du framework. Il faut cependant relativiser cet enthousiasme :
- Que vaut wicket sur des fonctions avancées comme la validation de formulaire ou un workflow d’écran avec suivant et précédent ?
- Est-il seulement un buzzword du moment ou va-t-il perdurer ?
Alors qui est le gagnant ?
- Catégorie « Couverture », l’équipe Struts2 a implémenté le plus de fonctionnalités, c’est indéniable. En revanche déception vis à vis du rendement !
- Catégorie « Découverte », Wicket a été une révélation pour beaucoup d’entre nous ! Une fois passée la barrière de la découverte, le développement est rapide et efficace.
Pour des raisons évidentes de bonne moralité, nous ne pouvons mettre en ligne les différentes applications développées …
Pour avoir testé Wicket sur un projet pour lequel j’ai environ 0.5 heures dispo par semaine, c’est effectivement un outil très pratique.
Concernant la doc, c’est effectivement très pauvre, puisque même le wiki officiel est plein de trous.
Heureusement, un téléchargement des sources et un peu de fouille au corps peuvent rendre de grands servcies.
Concernant l’internationalisation, ça semble un point très travaillé, mais je n’ai pas encore eu le temps de me pencher dessus.
Pour la validation de formulaire, il me semble qu’il « suffit » d’nevoyer des exceeptions lors de la phase de validation (qui a lieu dans le onSubmit) pour pouvoir afficher un message d’erreeur. malheureusement, je ne trouve pas ça suffisant pour la validation champ apr champ, qui se fait je crois en Ajax.
Les suivants/précédents sont, d’après ce que j’ai compris, gérés grâce à un système de versions des pages.
Quant au buzzword ou pas … tout comme pour Struts, seul l’avenir nous le dira.
On pourrait argumenter longtemps sur le choix des 4 frameworks retenu, son petit préféré n’étant pas présent. Le résultat parait néanmoins raisonnable : Struts2, en tant que « successeur » de Struts, parce qu’il le faut bien ; GWT en représentant du « client lourd sur le net » ; Wicket pour le buzz qu’il génère depuis pas mal de temps et son côté rafraichissant (c’est vrai que faire du Swing pour internet, c’est très novateur ^^) ; et un framework composant/évenementiel, parce qu’il parait que certaines JSR en parlent, et que c’est à la mode. Donc JSF, par ce que c’est ce que Sun nous a imposé.
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
[...] ce qu’a tenté Xebia sur le développement d’une couche présentation dans leur “Xebia Web Framework Contester“. Les frameworks testés sont [...]
Cet article est très intéressant. J’aurais juste une petite remarque concernant la partie JSF : j’ai toujours eu beaucoup de problèmes avec l’utilisation des MyFaces. Je vois de plus en plus de projets partir sur IceFaces (qui est maintenant open-source et gratuit). Il y a une communauté très active, des forums, la doc est excellente, et ces tags sont utilisés sur de gros projets.
Très bonne news de retour techno, continuez comme ca.
Avez-vous des retours sur Seam de JBoss?
Merci.
Seb.
@Iguane39 : retour de copains qui l’ont utilisé : c’est une très bon framework « full stack » (à la Rails : gestion de toutes les couches). Par contre, apaprement faut vraiment rester en full JEE5 pour rester dans la facilité d’utilisation du Framework.
Et toujours selon eux, le module eclipse pour SEAM est bien.
Conclusion :
, mais ca semble une bonne façon d’en faire de manière un peu moins fastidieuse ;
- 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
- 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.
[...] Flux RSS « Xebia Web Framework Contest [...]
Très bon article de Benoit, et par ailleurs je vais aller (re)voir Tapestry qui semble intéressant.
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 ?
« Il n’est pas possible d’utiliser directement du code HTML à l’intérieur de tags JSF ! »
Par défaut, c’est vrai.
Cependant, avec l’ajout des Facelets, cela devient possible, tout comme la gestion de templates (très pratique pour homogénéiser ses écrans).
De même, JSF n’a vraiment d’intérêt que couplé avec une (ou des) librairies de composants tierces, telles que RichFaces, Tomahawk, etc.
De base JSF, qui est un framework basé sur les composants, ne propose qu’un « coeur » un peu trop épuré à mon goût…
Bonjour,
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.
« L’équipe avait préparé un template de projet Struts2 avant le XKE, projet Eclipse/Maven 2, web.xml déjà configuré, librairies installées, et différents tests “Hello World” de plugins (zero conf, etc…). »
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 !
Le principe est marrant mais les resultats peu convaiquants.
En effet les remarques sur JSF ne sont pas justifiées.
Seam manque à ce contest, c’est un framework très complet et si c’est en effet un framework « full stack », ses apports sur la seule partie WEB sont déjà très interessants. Je vous encourage vivement à utiliser Seam pour la prochaine version du contest (et pensez à prendre le plugin Seam pour eclipse et les tags JSF RichFaces).
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…
Bonjour,
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)
Bonjour,
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.
Le « buffer JSF » fait référence à sa gestion d’arbre de composants. Les tags JSF n’écrivent pas directement dans le writer JSP, mais ils ajoutent des UIComponent à un arbre de composants, lequel est rendu en fonction du renderer kit utilisé (HTML par exemple). Et tous les composants du tag doivent être des composants JSF. C’est pourquoi il faut entourer le code html avec un tag .
Guillaume (Xebia)
[...] Xebia Web Framework Contest [...]
[...] Nous annoncions lors de la revue de presse du 12 novembre dernier son passage en RC, et bien c’est maintenant officiel : Apache Wicket 1.3 fait maintenant partit de la volumineuse liste des java web framework disponibles sur le marché. Malgré cette farouche concurrence, le buzz continue : Wicket est l’un des web framework faisant le plus de bruit sur la toile, ses promesses sont simples : simplicité d’utilisation, POJO-centric, pas de configuration XML … donnez votre sur le billet du Xebia Web Framework Contest. [...]
[...] En incluant des débats (Exemple : Les EJB ont-ils un avenir?) ou des concours sur une journée (Exemple : Web Framework Contest). [...]
[...] certain coût d’entrée… (Nous avions partagé certaines de ces conclusions dans notre Web Framework Contest en Octobre [...]
terrible ce concept de contest. dommage qu’il n’y ait pas eu Tapestry 5
dans la liste j’aurais vraiment aimé avoir un comparatif Tapestry 5 vs Wicket
ça aurait été intéressant d’avoir une équipe no framework aussi, pour bien
mesurer le gain de productivité des différents framework.
merci
[...] du Xebia Web Framework Contest, nous avions omis de mettre en compétition le framework d’Apache, Tapestry. Plus récemment, [...]
Bon article, même si vous êtes un peu à côté de la plaque pour JSF. Pour les messages d’erreur il suffit d’ajouter un tag mais pour savoir ça il faut consacrer 2 heures à lire la doc..
Bonjour Julien,
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)
[...] le Xebia Web Framework Contest de l’année dernière, le thème du XKE du mois d’Octobre était un nouveau contest [...]
[...] Xebia Web Framework Contest – a contest where different teams had to develop the same application using different Java [...]