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. , etc.).
• 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 équivalent (perfs ?).
• 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 …