{"partition": "head_middle", "source_domain": "blog.xebia.fr", "digest": "sha1:CS6A33KNCEFZXP4XACPBJIRQPDZLADLB", "path": "/lustre/fsn1/projects/rech/qgz/uzq54wg/processed_redpajama/base_processing/output/fr/2014-15/000_00003.parquet"}
(402)Simplifiez vous le monitoring avec Metrics (341)POST vs. PUT : la confusion (307)Revue de Presse Xebia (283)Revue de Presse Xebia (255)Xebia participe à la FrenchTech Safari le 19 avril (216)Revue de Presse Xebia (204)Nos dernières vidéos	Benoit Moussaud
Vendredi 26 octobre
Java / JEE
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.
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).
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).
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