La revue de presse de l’actualité Java/JEE hebdomadaire proposée par Xebia.

Le coin de la technique

• Sortie de Grails 1.4M1
• JRebel « reloaded » en V4
• Selenium 2.0 RC1

Evénements de notre communauté en France et à l’étranger

• Xebia poursuit l’aventure au challenge Octo 2011

Le coin de la technique

Sortie de Grails 1.4M1

La première Milestone de Grails 1.4 vient de pointer le bout de son nez ! Au programme :

• Mise à jour de la stack par défaut : Spring 3.1 M1, Groovy 1.8, Hibernate 3.6, Servlet 3.0 et Tomcat 7.0
• Remplacement de HSQLDB par H2 pour la base de données de développement
• Amélioration du rechargement à chaud pour plus de confort du développeur
• Intégration par défaut du plugin resources pour gérer les header HTTP expires, les packages de ressources statiques et autres joyeusetés

Pour tous les détails, allez voir les releases notes. Maintenant il va falloir tester tout ça et remonter un maximum d’informations chez SpringSource. A vos marques, prêts ? Testez !

JRebel « reloaded » en V4

Le fort sympathique JRebel vient de sortir en V4.0. Cette librairie, qui s’intégre dans vos IDE préférés, vous permet de modifier à chaud le code pour observer directement le résultat. Bien sûr, vous modifiez sans doutes déjà votre code grâce au hotswap de Java 1.4, mais JRebel permet bien plus. Avec lui, vous n’êtes plus limité au changement de code dans le corps des méthodes: presque tout vous est permis ! De plus, son système de plugins, disponibles pour la plupart des frameworks connus, permet de recharger toutes les ressources qu’une simple modification de bytecode ne pourrait prendre en compte. Vous rajoutez un bean dans l’applicationContext.xml ? Pas de problème, il est déjà en mémoire.
Parmi les nombreuses nouveautés, les plus marquantes sont:

• le support complet des EJB 3 et de Seam 2
• utilisation des API standard Instrumentation/Hotswap pour de meilleures performances
• un meilleur support du rechargement des classes anonymes

Cette dernière nous a particulièrement marqué. Pour du développement sur Wicket par exemple, où l’on a généralement beaucoup de classes anonymes, c’est une amélioration bienvenue: adieu les SuperClassChangedException ! C’est donc une bonne nouvelle pour tous les chanceux utilisateurs de l’outil qui n’est, rappelons le, pas gratuit mais dispose d’une période d’essai de 30 jours.
Rappelons aussi que tester et modifier son code en live, c’est bien, mais que faire des tests unitaires permettant de « blinder » toute modification, rapidement et en se passant de serveur, c’est encore mieux !

Toujours chez Zeroturnaroud, notons aussi cette semaine les résultat de leur sondage sur la façon dont sont mises à jour les applications en production. Le sondage est fait sur un petit nombre de personnes (607) et le panel représentatif ne doit pas être si représentatif que ça (tous les sondés connaissaient sans doute déjà JRebel). Néanmoins, il fait ressortir le manque de standardisation et de confiance envers cette étape pourtant cruciale de la vie d’une application. L’un des futurs chantiers auxquels devra s’attaquer Oracle ? En tout cas, l’article note que notre DeployIt va dans le bon sens, c’est toujours ça.

Selenium 2.0 RC1

Ce projet lancé en août 2009, réalise la fusion des API de WebDriver et Selenium. Les deux projets proposent une solution d’automatisation des tests d’applications web, avec à chacun leurs avantages et leurs inconvénients. Selenium de son côté repose sur un moteur JavaScript exécuté dans le navigateur avec les limitations que cela implique. Tandis que WebDriver propose une solution reposant sur des extensions du navigateur ce qui lui donne accès à toutes les fonctionnalités natives sans les limitations de la sandbox JavaScript. Selenium 2.0 ou Selenium WebDriver est donc une réécriture profonde de l’outil qui intégre maintenant WebDriver. Le nouveau framework peut utiliser alternativement le moteur JavaScript ou l’extension native pour supporter un maximum de navigateur. L’API selenium 2.0 est maintenant considérée comme stable, c’est donc le bon moment pour tester cette nouvelle branche.
Parmi les nouveautés de cette version :

• Grid 2, permet de distribuer les tests WebDriver dans une grille Selenium.
• Chrome Driver, ce nouveau driver pour Chrome repose sur une extension native du navigateur.
• Opera, cette version embarque un driver pour le navigateur Opera.
• Advanced user interactions, cette nouvelle API permet de composer et de chainer des actions complexes à exécuter dans le navigateur.

La RC1 fût très rapidement suivie d’une RC2 corrigeant un problème de lancement sur IE.
Pour plus d’information:

• L’annonce sur le blog Selenium
• La documentation Selenium 2.0 et WebDriver

Evénements de notre communauté en France et à l’étranger

Xebia poursuit l’aventure au challenge Octo 2011

Il y a quelques mois, la société Octo lançait un challenge un peu fou : « Et si vous codiez une application qui supporte 1 milliard d’utilisateurs ? ». Nous ne sommes jamais en reste lorsqu’il s’agit de relever ce genre de pari. Portée par Julien Buret et Seven le Mesle, l’équipe Xebia a donc planché sur ce sujet, qui a déjà donné lieu à quelques débats enflammés lors de nos Xkes. Après une phase de qualification sur 5 VMs, le jury d’Octo a annoncé les 3 équipes sélectionnées pour aller encore plus loin sur une infrastructure comprenant 20 VMs. Et nous avons l’honneur d’en faire partie. Nous ne dévoilerons donc pas (encore) sur ces pages l’architecture mise en place. Mais nos lecteurs les plus assidus se doutent qu’elle tourne intégralement autour de l’écosystème JEE.
Par ailleurs, ce challenge nous a permis de défricher des thématiques peu communes dans les applications d’entreprise actuelles, et nous aurons l’occasion de revenir en détail sur quelques points particuliers de l’architecture de cette application massivement multijoueurs.

Comment choisir ces fameux Frameworks Web qui sont, et c’est le moins que l’on puisse dire, assez nombreux. Et bien tout d’abord, il va falloir restreindre cette liste à quelques Frameworks et, pour chacun d’entre eux, prototyper une application. A partir de ces prototypes, il sera alors possible de créer une matrice comprenant différents critères qui seront notés pour chaque Frameworks. De là, on pourra faire ressortir les meilleurs prétendants, un petit document et faire nos recommandations. C’est ce qu’a fait Matt Raible durant cette présentation et voici ses résultats !

Matt fait un petit rappel sur les facteurs clés qui nous permettaient de choisir un Framework Web en 2007 (de son expérience) :

• composant, requête ou RIA,
• facilité de développement,
• communauté autour du Framework,
• roadmap et futur du Framework,
• maintenance,
• fonctionnalités.

Aujourd’hui, nous en demandons beaucoup plus à nos Frameworks Web et, pour Matt, nous passons de 6 à 20 ! Avec un peu d’exagération sur cette fulgurante croissance car certains points faisaient déjà parti de nos préoccupations en 2007 ; de là à dire que ce sont de nouveaux points… En tout cas, les voici au complet :

• productivité du développeur,
• perception du développeur,
• courbe d’apprentissage,
• santé du Framework,
• disponibilité des développeurs (sur le marché),
• offres d’emploi,
• templating,
• composants,
• ajax,
• plugins ou add-ons,
• scalabilité,
• support pour les tests,
• i18n et l10n,
• validation,
• support du multi-langage (groovy, scala…),
• qualité de la documentation / tutoriaux,
• publications,
• support de REST,
• support mobile,
• et degré de risque.

Bien sûr, nous pouvons remettre en cause certains points de cette liste et passer plusieurs journées à en débattre mais le débat n’est pas là. Matt assume que les choix qui sont fait sont les siens et il nous invite à participer pour ajouter des éléments à la liste ou lui indiquer pourquoi il se trompe sur telle ou telle appréciation. L’idée est ici de donner une base solide afin de pouvoir comparer sur plusieurs points importants de nos projets d’entreprise ces fameux innombrables Frameworks Web.

Roulement de tambour… voici la matrice ! (google spreadsheet)

Les gagnants de ce « concours » sont :

• Spring MVC,
• GWT,
• Ruby on Rails (non JVM mais non exclu car très présent sur le marché),
• Grails,
• Wicket.

Vient ensuite une partie avantages / inconvénients pour chacun d’eux. Cette partie est à prendre avec des pincettes car les inconvénients relevés sont souvent surmontables (certains sont même juste des comportements par défaut modifiable par configuration !) mais encore une fois cela donne un overview de ce que font ou ne font pas ces Frameworks :

• Spring MVC : configuration simple par conventions et annotations, intégration de plusieurs formats d’affichage (JSP, JSTL, FreeMarker, JSON, PDF…) et excellent support de REST mais pas de rechargement à chaud par défaut (toutefois possible avec JRebel ou Spring Roo), projet non ouvert à la communauté pour contribution (SpringSource mandatory) et pas de librairie ajax en bundle (ce qui peut aussi être vu comme un point positif car mise à jour des librairies Javascript non bloquée par le Framework) ;
• GWT : code Java traduit en un Javascript extrêmement optimisé, apprentissage facile et rapide (petit bémol car sur ce point les développeurs Web n’ont pas forcément cette compétence du code Swing-like) et une communauté vibrante mais il faut connaître Java (alors que l’on produit du Javascript), compilation très lente et code difficile à tester ;
• Ruby on Rails : apprentissage rapide pour tout développeur Web, documentation abondante et communauté de passionnés mais moins performant que les autres langages, langage dynamique = plus de tests pour éviter les cast exceptions au runtime et un manque d’outils de développement et de débugger comme dans le monde Java ;
• Grails : transition facile depuis le monde Java, utlise Groovy et nombreux plugins mais Groovy vise directement les développeurs Java (ce qui peut bloquer d’autres développeurs), stack traces affreuses (dans le slide ) et connaissances des sous-modules non nécessaires mais peut aider ;
• Wicket : parfait pour les développeurs Java, binding des pages et des vues et communauté active mais pas ou peu d’offres d’emploi, stateful par défaut et templates HTML juste à côté des classes Java (ce qui ne va pas aider le graphiste).

Pour finir, nous avons droit à quelques jolis graphiques qui nous montre à quelle point Ruby On Rails est très présent au niveau de la communauté mais ainsi en terme d’offres d’emploi.

Matt a insisté sur deux points importants tout d’abord sur le fait que ce sont les développeurs qui devraient choisir leur framework web, plus les développeurs sont heureux, plus ils seront productifs. D’autre part, javascript n’est pas si difficile comme on l’entend souvent de la part des développeurs java, plus on le pratique, plus on l’apprécie, et c’est vital si l’on veut être sérieux pour le développement d’application web.

Cette méthode peut être appliqué dans votre entreprise pour choisir votre framework web :

1. priorisez les fonctionnalités importantes de votre application
2. sélectionnez ensuite 3 ou 4 Frameworks pour prototyper une application (1 semaine chacun), documentez
3. calculez votre matrice et choisissez !

Actualité éditeurs / SSII

• Avancement des spécifications et implémentations JEE 6

RIA

• Des nouvelles d’Ext-GWT

Le coin de la technique

• Nouveau concept dans JUnit 4.7 : Rule
• Attention à votre mémoire avec String.substring()
• Sortie de Wicket 1.4
• Chouchoutez vos tests unitaires.

Evènements de notre communauté en France et à l’étranger

• Sun perd JRuby

Actualité éditeurs / SSII

Avancement des spécifications et implémentations JEE 6

Le dernier podcast des Cast Codeurs a été l’occasion de faire un tour de table des informations que chacun des speakers possédait sur JEE 6. Même s’il ne s’agit pas d’informations officielles, elles offrent un aperçu intéressant sur ce que pourrait être JEE 6 lors de sa finalisation ainsi que sur son calendrier :

• Antonio Goncalves, membre de l’Expert Group JEE 6, explique que la bataille entre les JSR-330 (Dependency Injection for Java) et JSR-299 (Java Contexts and Dependency Injection) sur le terrain de l’injection de dépendances semble partie pour se terminer de manière constructive. En effet la JSR-330 ne présentant pas d’incompatibilité particulière avec le modèle très évolué proposé par la JSR-299, les deux spécifications devraient se compléter harmonieusement. La JSR-330 définirait un ensemble d’interfaces de base que la JSR-299 viendrait étendre pour ajouter ses concepts plus élaborés. Afin de permettre cet ajustement de dernière minute, la finalisation de la spécification JEE 6 serait légèrement repoussée, la portant ainsi autour d’octobre / novembre 2009.
• Emmanuel Bernard, travaillant sur les problématiques de persistance chez JBoss, nous apprend quant à lui que l’implémentation des drafts des spécifications JEE 6 est en cours chez JBoss et devrait aboutir en version 5.2 du serveur d’application de l’éditeur avec une première implémentation non conforme au TCK, la conformité viendrait dans un deuxième temps, lors d’une version ultérieure. Il évoque la possibilité d’une présentation de ce travail lors du JBoss World de début septembre. D’autre part, la JSR-303 (Bean Validation) dont il est responsable est proche de la finalisation mais un conflit avec le JCP sur une problématique de licence complexifie l’avancement.

On ne peut que se réjouir de cette éventuelle harmonie entre les deux JSR d’injections de dépendances puisque les développeurs seraient ainsi libres de choisir la spécification sur laquelle ils se basent, en fonction de leur besoins plus ou moins complexes.

RIA

Des nouvelles d’Ext-GWT

Ext-GWT, la librairie Javascript ExtJS portée en GWT (cf. article sur la galaxie GWT), sort en version 2.0.1.
Profitons de cette sortie pour parler plus globalement du projet et de la release majeure 2.0 sortie il y a maintenant un mois.

Celle-ci apporte en effet son lot de nouveaux composants et nouvelles fonctionnalités. Ces ajouts réduisent ainsi l’écart entre les 2 projets. On trouve ainsi :

• le Tree Panel et le Tree Grid (démo), ce dernier (qui étend directement le composant Grid donc plus de binder) bénéficiant de toutes les fonctionnalités du tableau
• le row editor (démo) qui permet de modifier une ligne complète du tableau, toutes les cellules de la ligne passant en mode édition (alors qu’avant il fallait éditer toutes les cellules une par une)
• le HTML editor / Rich Text Editor (démo)
• le Live Charting (démo) qui rejoint ainsi GChart (évoquée lors d’une précédente revue de presse) et OFCGWT
• le ButtonGroup (démo) et le Status (démo)

Un travail important a été apporté sur les boutons, la barre d’outil, la gestion de l’overflow dans cette barre…

Les nouveautés étant très nombreuses, un détour par le fameux showcase permettra de les parcourir/tester.

S’agissant d’une mise à jour majeure, un guide de migration présent dans le produit décrira les changements dans l’API.

Téléchargement par ici et si (comme moi ) vous attendez déjà la suite avec la 2.1, vous trouverez la nouvelle roadmap par là.

Le coin de la technique

Nouveau concept dans JUnit 4.7 : Rule

La version 4.7 du célèbre framework de test unitaire, JUnit, est en cours de préparation. Un nouveau concept a été dévoilé : Rule.

Ce concept va réjouir les accrocs du test automatisé par JUnit. En effet, cette fonctionnalité permettra de modifier l’exécution de vos tests, afin de les préparer à un contexte d’exécution.

Un des exemples les plus significatifs est le suivant :

 public static class HasTempFolder {
   @Rule
   public TemporaryFolder folder= new TemporaryFolder();
   @Test
   public void testUsingTempFolder() throws IOException {
     File createdFile= folder.newFile("myfile.txt");
     File createdFolder= folder.newFolder("subfolder");
     // ...
   }
 }

Grâce à cette déclaration @Rule public TemporaryFolder folder= new TemporaryFolder();, avant le test il n’y a pas besoin de créer de répertoire temporaire, après le test il n’ y a pas besoin de supprimer les répertoires et fichiers créés pendant le test. Cela permet donc plus facilement de faire des tests automatisables, répétables, et portables d’environnement à environnement.

Il existe d’autres Rules comme par exemple :

• ExternalResource: utilisable d’un fichier externe (accessible par système de fichier)
• Timeout: le test doit répondre avant un timeout
• ExpectedException: le test doit jeter des exceptions bien déterminés
• Et bien d’autres

Il y aura donc un ensemble de Rules qui permettront d’éviter de refaire des petits bouts de code personnel pour faire la même chose en une annotation.

Attention à votre mémoire avec String.substring()

Voici un article intéressant qui permet de comprendre ce qui se trouve sous le capot de la classe du JDK String : String and memory leaks ; il pourrait même vous donner une petite goutte de sueur sur le front. Même si le titre de l’article n’est pas forcement bien choisi (‘fuite mémoire’ alors qu’il s’agit plus de rétention mémoire), il nous montre simplement comment une méthode de la classe, substring, peut cacher un loup.

En effet, à des fins d’optimisation, on fait tourner le code suivant :

public static void sendEmail(String emailUrl) {
    String email = emailUrl.substring(7); // 'mailto:' prefix has 7 letters
    String userName = email.substring(0, email.indexOf("@"));
    String domainName = email.substring(email.indexOf("@"));
}
public static void main(String[] args) {
    sendEmail("mailto:user_name@domain_name.com");
}

A première vue, on a trois instances de la classes String :

• String email = "mailto:"
• String userName = "user_name@"
• String domainName = "domain_name.com"

Cependant, concrètement, en mémoire il n’y a qu’un tableau de char qui est stocké : "mailto:user_name@domain_name.com", les instances des classes String enregistrent seulement les intervalles utilisés du tableau de char.

Le piège est de manipuler une grosse chaine de caractères (qui vient d’un fichier batch par exemple) et d’utiliser substring afin de limiter la taille de la chaine et donc l’utilisation mémoire. Faux ! La chaine initiale sera toujours stockée en mémoire.

Assez déroutant !

Sortie de Wicket 1.4

Le projet Wicket continue d’évoluer et, alors que nous vous parlions d’une version 1.3.6 en mai dernier (qui a d’ailleurs fait l’objet d’une Refcard DZone), c’est la version 1.4 après un an de travail qui nous arrive dans la mains (par Yes Wicket ! et Apache Wicket).

Au menu des nouveautés : un nouveau packaging des jars Wicket (qui les rend compatibles OSGi), un seul jar pour les modules Spring et plusieurs modifications d’IModel, de ses implémentations et plus globalement des APIs pour tirer avantage de Java 5 (Generics…). L’utilisation des Generics dans le code de Wicket a commencé il y a environs un an par un sondage passionné sur la mailing-list, pour arriver seulement dans la milestone 3 de Wicket 1.4 avec autant de partisans que de détracteurs – défenseurs du support du JDK1.4- et ceci jusqu’à la release final. Le thread sur The Server Side est également impressionnant ! Pour le détail complet, rendez-vous sur le Jira du projet.

Tout comme pour Ext-GWT 2.0 (ci-dessus), une guide de migration de 1.3 vers 1.4 est disponible. Un petit téléchargement ?

Chouchoutez vos tests unitaires.

InfoQ publie un intéressant florilège : « Réalisez de meilleurs tests unitaire ».
Certains trouveront que, de nouveau, on enfonce des portes ouvertes. D’autres (comme nous), apprécierons les nombreuses réactions qui découlent de ce genre d’article, et penserons qu’il n’est jamais inutile de rappeler ces grands principes de base afin d’arrêter de voir des tests unitaires martyrisés (et inutiles) sur certains projets.
Bref, en un mot comme en mille, vos tests unitaires sont des classes de code java, qui sont vitales pour vos projet, il est donc urgent d’en prendre grand soin (nommage, documentation, refactoring…)

Evènements de notre communauté en France et à l’étranger

Sun perd JRuby

Trois développeurs clés de JRuby, à savoir Charles Nutter, Thomas Enebo et Nick Sieger, ont choisi de quitter Sun MicroSystems. Suite au rachat récent par Oracle et à l’incertitude concernant le support de JRuby par le nouveau propriétaire, ils ont décidé de rejoindre la société Engine Yard, spécialisée dans l’hébergement d’applications Ruby On Rails. Engine Yard a l’air enthousiaste à l’idée de pouvoir être le support du développement de l’offre JRuby et de la communauté qui va avec. (Source)

Voilà pour le principe de cette approche qui semble avoir de beaux jours devant elle. Emergence naturelle ou stratégie voulue, la fondation Apache, jamais avare de solutions, nous propose deux frameworks composants : Tapestry 5 et Wicket. Alors comment choisir ? Le mieux est encore de se faire sa propre idée en les testant tous les deux. Nous sommes bien d’accord, rien ne remplacera jamais l’efficacité du prototypage. Cela n’empêche pourtant pas de faire une pré-sélection basée sur quelques points de comparaisons stratégiques. Voici donc un article pour vous aider à faire le meilleur choix ; à savoir le choix qui répondra le mieux aux besoins et à l’environnement de votre projet.
Bien qu’adoptant tous deux la programmation web orientée composant, les deux projets sont imprégnés d’une philosophie et d’un objectif différents. Les buts principaux de Wicket sont :

• Pages et composant statefull
• Programmation à la Swing
• Séparation stricte entre code et template

Pour Tapestry 5, les objectifs sont différents :

• Optimiser l’utilisation CPU et mémoire
• Simplifier la création de composants

Attention ! Ce sont là les objectifs sur lesquels les deux projets sont focalisés. Ce qui ne signifie pas qu’ils s’y intéressent exclusivement. Wicket supporte bien les composants sans état, ce n’est juste pas son but principal. De même que Tapestry supporte le développement web entièrement en objet Java.

Ils affichent, aussi, des buts communs, comme d’être orientés Pojo et d’éliminer la configuration XML avec le pattern Convention Over Configuration.

Configuration

Pas de XML ne veut pas dire pas de configuration. La différence consiste à configurer l’application avec du code Java. Dans le cas de Wicket, il s’agit de construire une classe héritant de WebApplication et, de la fournir en paramètre du contexte web. Dans la WebApplication, il faut fournir la classe correspondant à la page d’accueil en surchargeant la méthode getHomePage(). Pour définir les paramètres globaux de l’application, il faudra utiliser les getters et setters de la classe mère.

De la même façon, avec Tapestry, il faut d’abord ajouter le TapestryFilter, puis déclarer le package principal de l’application en context-param. Par défaut, Tapestry va considérer que le package myapp.services contient des services Tapestry IoC, que le package myapp.components contient des composants, et que le package myapp.pages contient des pages. L’application est configurée à partir d’une classe Pojo myapp.services.AppModule. Il s’agit en fait d’un module Tapestry-IoC qui, via des noms de méthodes conventionnels, va permettre d’affiner la configuration du framework et de monter nos propre services. En ce qui concerne la page d’accueil, par défaut, Tapestry chargera la page nommée Index.

Pages et composants

Dans Tapestry 5, les pages comme les composants sont des pojo décorés par des annotations et/ou utilisant des noms de méthodes conventionnels. Les annotations permettent d’injecter avec Tapestry IoC des services ou des composants. Elles sont aussi utilisées pour écouter des événements via des méthodes annotées. Certains noms de méthodes sont reconnus et utilisés par Tapestry pour recevoir les événements (onActionFromComponentId() par exemple). Souvenez vous, la configuration exige de fournir des nom de package pour les pages et les composants. Tapestry lie toutes les classes contenues dans les packages pages et composants à ses annotations et, cerise sur le gâteau, les recharge à chaud.

Avec Wicket, pages et composants sont des classes construites par héritage qui fournissent un constructeur chargé de les composer. Dans le constructeur, il faut créer les composants, les lier aux template et les ajouter à la page comme on le ferait avec un conteneur Swing. Les modèles permettent de lier les données des beans aux composants, et de les maintenir. Parfois, il sera utile de surcharger quelques méthodes comme onSubmit() pour un formulaire.

Wicket	Cadre imposé par l’héritage	Nécessite un minimum de connaissances de l’API
Tapestry 5	Re-chargement à chaud Syntaxe légère	Instrumentation du code source

En clair, avec Wicket on développe une application web comme on le ferait avec un toolkit graphique. La transition pour les habitués du MVC sera plus difficile. Tapestry est plus modéré de ce point de vue avec ses Pojo qui ne manquent pas de rappeler les actions ou contrôleurs d’usage en MVC. La possibilité de créer des composants réutilisables est bien au rendez-vous, par contre il faudra faire très attention au choix des identifiants qui doivent être uniques pour le couple page – composant. Impossible d’échapper au piège des identifiants uniques, quand il s’agit d’ajouter plusieurs fois le même composant dans une page par exemple.

Les templates

Dans les deux cas, les templates sont des fichiers XML composés de tags HTML et de quelques ajouts dans un espace de nom spécifique aux frameworks. Ils proposent tous deux de décorer le HTML avec des attributs spécifiques ou bien de directement ajouter des tags qui représentent les points d’ancrage des différents composants. Pour établir la liaison entre le code Java et le template, chaque composant est ajouté dans le template avec un identifiant unique qui est utilisé plus tard dans le code. Par défaut, les templates doivent porter le même nom que la classe auxquels ils se rapportent, ce qui inclut bien sûr le nom du package.

Wicket impose une séparation stricte entre code et template. Des attributs spécifiques Wicket (wicket:id= »monId ») sont ajoutés au template pour définir l’identifiant des composants. Dans le code, les composants sont liés au template en fournissant leur identifiant comme paramètre du constructeur. En opposition au JSP et autre Freemarker, il n’y a plus de code ou de pseudo-code dans le template, toute la partie dynamique est développée en Java pur. Pour gérer la mise en forme des pages (menu, en-tête et pied de page), Wicket propose l’héritage de template sur le même principe que sitemesh. Un tag est ajouté dans le template de la page mère, pour indiquer le lieu ou sera intégré le contenu surchargé par les template fils. Les templates fils, doivent, de leur côté , contenir une balise wicket:extend encadrant le HTML et les composants à injecter dans le template hérité.

La différence réside encore une fois dans le côté un peu plus laxiste de Tapestry qui favorise l’utilisation de pseudo-code dans le template. En définitive, les composants Tapestry fonctionnent un peu comme des Taglibs sans la configuration XML qui va autour. Ici, en plus de l’identifiant, les balises spécifiques supportent un nombre illimité de paramètres transmis sous la forme d’attributs XML ou de blocs de code HTML entourés du tag t:parameter. Les attributs peuvent être définis dans différents scope comme literal pour du texte, propertie pour des propriétés de la classe et bien d’autres. Tapestry fournit aussi un moyen d’injecter directement du texte ou du code HTML avec « des extensions ». Il suffit de placer entre ${…} le nom d’une propriété du composant pour que sa valeur soit injectée dans le rendu HTML. La mise en forme se fait par composition. Le template des pages est entouré par la balise d’un composant. Celui-ci doit alors définir un élément <t:body/> qui sera remplacé par le corps de la page.

Wicket	Séparation des rôles Clarté du code HTML	Syntaxe déclarative très verbeuse dans le code Java
Tapestry 5	Très proches des JSP et autres Freemarker Instanciation implicite des composants	Layout par composition, moins intuitif que l’héritage

Force est de constater le côté plus laxiste de Tapestry 5, qui donne une plus grande liberté pour la rédaction des templates HTML, et qui surtout dépayse moins du J2EE traditionnel. Cette liberté a bien sûr un coût car elle permet au développeur de faire à peu près tout et surtout n’importe quoi. Il faudra garder un œil attentif à ce que font les développeurs, pour éviter de se retrouver avec un code illisible.

Principe de navigation

Dans les deux cas, la navigation est assurée par des composants de type Link ou Form qui lèvent des évènements en relation avec les requêtes de l’utilisateur. C’est la méthode captant l’évènement qui va définir la Page à retourner au client.

Pour Wicket, il faut appeler explicitement setResponsePage(…) dans la méthode du composant captant l’évènement. Ici, Il est possible de fournir une classe, ou une instance de Page. Par défaut, les URL sont générées pour la durée de vie de la session; mais il existe une alternative basée sur des BoorkmarkableLink permettant de créer des liens persistants. A chaque appel, les objets composants et pages sont instanciés puis stockés en session, seuls les templates sont stockés dans un cache qui permet d’accélérer le rendu et de recharger les templates à chaud pour le même prix.

Chez Tapestry, c’est le retour de la méthode captant l’évènement qui détermine la page ou le contenu de la réponse HTTP. Au développeur de choisir le type de retour, une chaîne pour le nom de la page, la classe de la page, la page instanciée, ou d’autres type de retour comme les objets JSON et les Stream. Les URL sont générées en REST de manière à assurer leurs persistance côté client. Notez que les pages sont instanciées une fois, puis conservée dans un pool pour être réutilisées par n’importe quelle session. Les pages passent donc par une phase de nettoyage après chaque utilisation. Il faut définir des méthodes onActivate et onPassivate pour récupérer le ou les paramètres stockés dans l’URL et charger les données en conséquence. Une annotation permet aussi de stocker des données en session pour les inconditionnels du genre.

Wicket	Contrôle des objets Pages Pas de code injecté au runtime	Force l’instanciation de nombreux objets
Tapestry 5	URL Rest Econome en mémoire	Force à gérer attentivement l’état des composants

Il faut retenir tout de même, pour l’un comme pour l’autre, qu’aucune configuration XML n’est nécessaire.

Validation

Inutile de dire que la validation fait partie des conditions sine qua non à l’utilisation d’un framework web. Ici encore, le principe est le même. Il s’agit d’ajouter des validateurs prédéfinis aux composants du formulaire. Les deux projets fournissent sensiblement la même liste de validateurs natifs, avec une légère avance pour Wicket. Reste une différence importante. Tapestry est le seul à fournir une validation serveur et client. Mais il le fait au prix d’une grande restriction, sur l’initialisation des validateurs, qui ne peut traiter qu’un seul paramètre de type chaine (JavaScript ?). Pour ce qui est des validations un peu plus avancées, il faut se tourner vers l’évènement Tapestry onValidate qui permet d’ajouter des erreurs à la validation du formulaire. De l’autre côté, Wicket propose de créer et d’ajouter au formulaire des IFormValidator qui permettront de faire de la validation sur plusieurs champs. Au final, Wicket a l’avantage de configurer la validation entièrement en Java. Dans Tapestry il faut plutôt la définir directement dans le template via un attribut validate.

Ici, pas de miracle, les solutions proposées sont assez simplistes et ne répondront sans doute pas d’emblée aux logiques de validations compliquées. Elles fournissent tout de même un cadre propre pour la validation qui permettra, avec un peu de développement, de répondre à peu près à tous les besoins.

Tapestry 5	Validation côté client	API restrictive en terme d’ajout de validateurs Déclaration des vallidateurs dans le template trop verbeuse
Wicket	API pensée pour la personnalisation des validateurs	Pas de notion de validation métier

Intégration d’autres Framework

Spring est évidement de la partie, chacun y allant de son annotation pour injecter des beans. Après un peu de plomberie, pour monter la WicketApplication en singleton Spring et lui ajouter la fabrique Spring en tant que ComponentInstanciationListener, il devient possible d’utiliser @SpringBean(name= »… ») pour injecter ses services dans les composants.

Dans Tapestry, il suffit de remplacer le TapestryFilter, précédemment utilisé, par le TapestrySpringFilter puis d’ajouter toujours dans le web.xml la configuration standard de Spring, à savoir un ContextLoaderListener responsable du chargement des différents applicationContext.xml. A partir de là, Tapestry-IoC inclut les beans Spring et les rend disponibles via l’annotation standard @Inject.

En plus de Spring, Tapestry fournit une extension pour Hibernate qui permet de le configurer rapidement et de gérer les transactions avec une annotation @CommitAfter. Cela manque un peu d’intérêt à mon goût, dès lors que Spring est utilisé dans le projet, mais cela peut permettre de s’en passer plus facilement.

Pour le JavaScript, Wicket a choisi de camper sur le serveur et de ne rien embarquer en terme de script client. Est-ce un bien ? Est-ce un mal ? En tout cas, Tapestry voit les choses différemment et embarque nativement la librairie PrototypeJS, ainsi que Scriptaculous. Grâce à cela, il fournit out-of-the-box des composants Ajax et la validation client. L’API JSON.org est utilisé pour les requêtes asynchrones et pour l’initialisation des composants JavaScript. Pas d’inquiétude à avoir, si Wicket n’intègre rien au départ, il est très simple d’embarquer JQuery par exemple.

Pour pouvoir bénéficier de composants Web 2.0 avancés et intégrer d’autres librairies comme GWT, Seam ou que sais-je encore, il faut se tourner vers les contributions. Les deux projets listent un certain nombre de sites de contributions, mais il faut un peu de chance pour tomber sur des composants maintenus. De ce point de vue, la communauté Wicket semble plus active.

Conclusion

A la fin, je suis bien forcé de constater que les deux frameworks se valent. La différence se joue un peu sur la performance et beaucoup sur le goût. En clair, si le cahier des charges prévoit une charge importante avec haute disponibilité et scalabilité, Tapestry sera un meilleur choix. Mais ce sera au prix d’un effort sur la gestion des données persistantes par rapport à Wicket. Pour le reste, il faudra choisir : le développement à la Swing et les composants par héritage de Wicket, ou les template par composition et les composants annotés de Tapestry. J’ai quant à moi une préférence pour Tapestry 5 qui propose une approche plus naturelle pour les habitués du développement web MVC. Ceci n’enlève rien à Wicket, qui est plus rigoureux et ne souffre d’aucune lenteur.

• Hands on Wicket
• Wicket
• Tapestry 5

SOA

• Fuji, le futur d’OpenESB

Le coin de la technique

• Concevoir des APIs efficaces
• JavaFX : informations et controverses
• Sortie de Wicket 1.3.6
• @Inject standardisation de l’injection de dépendances
• Sortie de Tapestry 5.1
• Trucs et astuces Json – Restfull

Evènements de notre communauté en France et à l’étranger

• Soirée Datagrid au Paris Jug

SOA

Fuji, le futur d’OpenESB

La prochaine version d’OpenESB, qui sera estampillée ‘v3′, est en cours de développement sous le nom de code ‘Project Fuji’. Ce projet a été récemment mis en avant par Andi Egloff, dans un webcast qui fait le tour des nombreuses nouveautés. Les principales d’entre elles sont :

• Integration Flow Language (IFL) : il s’agit d’un DSL externe permettant de définir des flux d’intégrations. Le rôle de ce langage est donc le même que le DSL interne offert par Apache Camel.
• Distributed JBI : La spécification JBI (JSR-208) ne couvre pas la problématique de distribution des composants JBI sur plusieurs noeuds. Fuji apporte une extension propriétaire pour permettre cette distribution.
• Utilisation de composants OpenJBI : ces composants seront utilisables directement dans OpenESB v3. Le projet prévoit de mettre les composants dont la compatibilité aura été validée dans le repository Maven du projet.
• Enterprise Integration Patterns : un certain nombre d’EIP sera supporté en standard et configurable via le langage IFL.

La version finale d’OpenESB v3 est prévue pour le second semestre 2009, l’équipe du projet annonce une probable preview pour JavaOne en juin.

Le coin de la technique

Concevoir des APIs efficaces

John De Goes vient de publier une série de deux articles (première partie et deuxième partie) portant sur les bonnes pratiques de conception d’APIs. Il s’appuie sur un exemple d’API de configuration pour illustrer son propos. Les points qu’il met particulièrement en avant sont :

• Il est important de sélectionner le niveau d’abstraction approprié et d’assurer l’uniformité de celui-ci sur l’ensemble de l’API, ainsi que de définir et respecter une responsabilité pour chaque classe. Ceci concerne la granularité des méthodes, le type d’objets manipulés en entrée et en sortie, ainsi que la présence et le type d’exception éventuellement renvoyée.
• N’offrir qu’une seule possibilité pour chaque besoin, afin d’éviter la confusion chez l’utilisateur de cette API.
• S’appuyer sur les possibilités offertes par le langage pour empêcher certaines mauvaises utilisations d’une API.
• L’API doit être la plus intuitive possible afin de minimiser autant que possible le besoin pour l’utilisateur d’avoir à se plonger dans une documentation.

Certaines de ces idées sont déjà partagées par de nombreux développeurs, mais comme c’est souvent le cas dans l’énonciation de bonnes pratiques ou de patterns, tout l’intérêt réside ici dans la formalisation apportée par l’auteur.

Les lecteurs intéressés par cette problématique pourront se tourner vers le livre de Jaroslav Tulach, Practical API Design, qui apporte l’intéressant retour d’expérience d’un architecte de NetBeans, ou encore How to Design a Good API and Why it Matters par Joshua Bloch (auteur de Effective Java).

JavaFX : informations et controverses

Depuis plusieurs mois, nous vous rapportons les différentes informations et controverses à propos de JavaFX. Cette technologie RIA, développée par Sun, et introduite en décembre 2008 fait beaucoup parler d’elle car personne ne sait dire aujourd’hui ce qu’il adviendra de JavaFX dans les mois et années à venir.

Les propos particulièrement négatifs dont JavaFX a été victime à ses débuts se font moins nombreux, non pas parce que cette technologie a convaincu, mais parce qu’elle n’est plus au centre des débats. En fait, ceci est bénéfique puisque cela permet d’observer plus sereinement les différents exemples postés régulièrement par la communauté JavaFX naissante. Il ressort de ce tour d’horizon que les capacités actuelles de JavaFX ne prêtent pas à critique : les fonctionnalités de graphisme et d’animations qui sont offertes semblent satisfaire de nombreux développeurs. Le problème porte principalement sur les manques et les promesses non tenues à ce jour :

• la portabilité de JavaFX sur plusieurs environnements (_desktop_, web, mobile, et TV, le fameux ‘All the screens of your life‘) n’est pas assuré puisque le déploiement est impossible sur mobile, faute de device compatible. Le fonctionnement sur téléviseur est lui toujours prévu dans une version ultérieure.
• les composants graphiques de haut niveau sont absents. Il s’agit pourtant d’un élément indispensable pour le développement d’applications RIA.

Joshua Marinacci, un des meneurs de JavaFX chez Sun, a été interviewé par Scott Hanselman dans un podcast. Il annonce que la démonstration de JavaFX sur TV pourrait être faite lors de JavaOne 2009, en juin. Il reconnaît par ailleurs le marketing excessif entourant cette technologie.

Outre ces réflexions d’ordre technique, le rachat de Sun par Oracle constitue une autre source de débats. Personne ne sait quelle décision Oracle prendra quant à JavaFX : soutenir ce projet qui nécessite encore un investissement lourd pour prétendre réellement concurrencer les autres acteurs RIA ou abandonner ce marché. Les différentes opinions sur ce sujet sont présentées et argumentées dans le dernier podcast des Cast Codeurs.

Sortie de Wicket 1.3.6

Wicket, le framework orienté composant de la Fondation Apache, sort en version 1.3.6 (1.4 toujours en release candidate 2).

Malgré les 7 mois d’écart avec la version précédente, il ne faut pas s’attendre à une révolution pour cette nouvelle mouture. Il s’agit en effet d’une version de stabilisation et d’amélioration. On notera donc de nombreux correctifs de bugs et plusieurs améliorations.

Cette version est téléchargeable sur le site d’Apache ou en changeant votre version de pom.xml en 1.3.6.

A noter, toujours autour de Wicket, le retour critique de Tom’s Quest sur Wicket et ses limites après la présentation, chez Zenika, de Martin Dashorst, un des committers principaux de Wicket et coauteur du livre Wicket In Action.

@Inject standardisation de l’injection de dépendances

Pas mal de bruit la semaine dernière dans la blogosphère Java avec l’annonce par Google et SpringSource d’une nouvelle proposition de JSR dédiée à l’injection de dépendances : @Inject (« Annotations for Dependency Injection »).
Comme le souligne ‘Crazy’ Bob Lee, l’auteur principal de Google Guice, la sortie de Spring 1.0, il y a déjà 5 ans, a apporté l’injection de dépendances aux masses, via un fichier de configuration propriétaire. Il y a 3 ans, Google Guice a proposé la même chose via des annotations (et SpringSource propose la même chose depuis Spring 2.5).
Si le succès de Google Guice est assez limité face au raz de marée Spring, le constat est là : il manque un standard. Comme les deux librairies ne sont pas compatibles, si vous exposez à un autre projet/équipe une librairie contenant des dépendances injectées par Google Guice, et que l’autre équipe utilise Spring, elle devra redéfinir tous les beans et leurs dépendances dans un fichier de configuration Spring (ou des annotations Spring).
@Inject propose donc de standardiser les annotations, afin de rendre portables sur différents frameworks (Guice, Spring, Tapestry IOC, etc.) des classes injectables.

Lire notre article à ce sujet : @Inject standardisation de l’injection de dépendances.

Sortie de Tapestry 5.1

Tapestry, dont on parlait récemment dans l’article l’injection de dépendances avec Tapestry IoC, passe en version 5.1 en respectant à la lettre son nouveau planning d’une version tout les 4 à 6 mois.
Outre les améliorations de performance et les nombreux bugs corrigés, la mise à jour embarque des nouveautés sur le support JavaScript, à la traîne par rapport au prédécesseur Tapestry 4.
Le rafraîchissement de plusieurs zones d’une page en une seule requête Ajax est maintenant supporté. Tapestry embarque maintenant la console JavaScript Blackbird.
Du côté des améliorations sur les templates, le chargement et le rendu des pages ont été optimisés, ce qui rend T5 plus rapide que jamais.
Vous pourrez aussi apprécier l’amélioration substantielle de l’archetype quickstart qui offre désormais une jolie interface, avec un design css intégré.
L’intégration de Spring est maintenant à double sens : on peut injecter des services Tapestry dans un Bean Spring.
Pour la prochaine version, qui sortira sans doute à la rentrée 2009, l’accent sera mis sur l’intégration de Spring Web Flow, et la possibilité d’utiliser une application Tapestry en tant que Portlet.

• Release note
• Site Maven du projet

Trucs et astuces Json – Restfull

Edwin Khodabakchian, fondateur de Collaxa (aujourd’hui au coeur de la stratégie SOA d’Oracle), nous donne quelques bonnes pratiques pour écrire des services web REST en utilisant Json (un couple qui a le vent en poupe). Actuellement lancé dans l’écriture de Feedly, une extension Firefox qui agrège des tweets et des entrés Google Reader, Edwin fera régulièrement profiter ses lecteurs de son expérience. Sans entrer dans les détails de ces bonnes pratiques, nous retiendrons l’astucieux découpage en 7 phases d’implémentation :

• Definir un service ou une ressource simple : définir le modèle Json et les 4 opérations REST et le servlet qui les fournit.
• Ecrire un client : utiliser le service avec un javascript simple. Cette possibilité est offerte par de nombreux frameworks, dont JQuery.
• Ajouter une étape de validation : modifier le service pour valider les ressources Json et utiliser les codes retour HTTP.
• Complexifier les ressources : modifier la hiérarchie d’Url pour servir des ressources plus riches. Tester la pérennité des ressources simples (phase 2).
• Ajouter un cache : améliorer les performances et la scalabilité de votre système.
• Implémenter la sécurité : utiliser une authentification web.
• Publier des événements business : pour découpler les processus REST des processus back-end. Les ressources REST sont traitées, un évènement business est lancé, qui déclenche le ou les traitements back-end.
• Gérer un cycle de vie pour les ressources : coupler un état de la ressource avec la phase de validation et la phase de publication des évènements.

Evènements de notre communauté en France et à l’étranger

Soirée Datagrid au Paris Jug

Le DataGrid au Paris Jug, c’est demain.
Pensez à réserver si ce n’est déjà fait.

Agilité

• Brûlez des Stories, pas des Tâches

RIA

• GraniteDS en version 1.2.0 GA
• Sortie du framework JavaScript JQuery 1.3
• Solution ORM en Javascript : Active Record JS
• Servlet 3.0 : une API innovante et convergente ?

Le coin de la technique

• Sortie de FEST-Swing 1.0
• Intégration Continue avec Maven
• Nouvelle version de RichFaces: la 3.3.0 est sortie
• LiquiBase 1.9 : Des améliorations bien utiles
• Comparatif de performance entre JSF/Seam à Wicket

Agilité

Brûlez des Stories, pas des Tâches

Beaucoup d’équipes Scrum sont habituées à décomposer les User Stories en tâches pour faciliter la répartition du travail dans l’équipe. Mais les problèmes arrivent dès lors qu’elles essaient d’estimer ces tâches (souvent en heures) et de les suivre.
Ron Jeffries suggère de ne pas utiliser de tâches. Il recommande d’utiliser les stories comme unité. Cela suppose que les stories soient suffisamment petites.

Chris Sims rappelle sur InfoQ quelques critères pour définir une bonne user story, que l’on retrouve dans le modèle INVEST (Independant Negotiable Valuable Estimable Small Testable).
Une story peut donc être réalisée par un seul développeur à condition qu’il ait les compétences pour la réaliser de bout en bout. Si votre équipe est spécialisée, vous pouvez y remédier à coup de pair programming.

Kelly Waters souligne que le sprint planning est allégé puisqu’il n’y a plus l’étape de décomposition en tâches.

Ron recommande également de suivre uniquement les stories sur le Burndown chart. Brûler les tâches donne l’impression d’avancer mais potentiellement aucune fonctionnalité ne sera livrable à la fin du sprint. Restez concentrés sur des fonctionnalités livrables, en vous aidant d’une bonne définition de terminé.

RIA

GraniteDS en version 1.2.0 GA

Une nouvelle version de Granite Data Services ou GraniteDS (solution serveur JEE pour le développement et le déploiement des applications Adobe Flex) est sortie avec de nouveaux supports pour :

• TopLink (Intégré dans GlassFish V2, Sun AS et Oracle AS).
• EclipseLink (Implémentation de référence pour JPA 2.0, intégré dans GlassFish V3).
• GlassFish (Un service de sécurité spécifique basé le service de sécurité de Tomcat).

La prochaine version de GraniteDS fournira un support d’OpenJPA et de JPOX/DataNucleus. Elle fournira également un service de sécurité spécifique pour les serveurs d’applications WebLogic. Toutefois avec la prochaine version vous aurez la possibilité de déployer la totalité de vos applications Flex/GraniteDS sur les serveurs d’applications WebLogic.

Pour voir la liste complète des nouveautés, rendez-vous sur le post suivant.

Pour se procurer gratuitement GraniteDs 1.2.0 GA, cela se passe ici.

Sortie du framework JavaScript JQuery 1.3

L’équipe de jQuery, un des frameworks JavaScript le plus en vogue aujourd’hui, annonce la sortie d’une nouvelle version : jQuery 1.3 and the jQuery Foundation.

JQuery est un framework JavaScript extensible. Il permet de manipuler plus simplement et de manière plus portable (d’un navigateur à un autre) le JavaScript. Il apporte une syntaxe élégante et légère pour la manipulation d’un document HTML d’un navigateur (arbre DOM et évènements).

Il apporte de base :

• un modèle d’événement (pression d’une touche du clavier, clic de souris, etc)
• un sélectionneur de noeud dans l’arbre DOM
• des routines pour le développement Ajax
• des routines d’animation graphique

La communauté jQuery est très active et elle développe de nombreux plugins JQuery, de la fonction JavaScript utilitaire au composant graphique riche, comme par exemple :

• routine pour la manipulation de formulaire : Form Plugin
• composant graphique pour la réalisation de graphe : jQuery Google Charting

La version 1.3 met à disposition différentes mises à jours:

• Performances améliorées avec un nouveau moteur de sélection CSS, une nouvelle méthode de ré-injection HTML (cf ci dessous le deuxième exemple), etc.
• Nouveau modèle d’événement : objet JQuery.Event
• Objet jQuery.support pour la détection de fonctionnalités spécifiques (ou de bugs) d’un navigateur.

Voici quelques exemples qui illustrent les capacités de JQuery :

// A la fin de chargement de l'arbre DOM par le navigateur
$(document).ready(function() {
// Attachement d'une fonction lors d'un clique à toutes les ancres
// (balise <a>) qui ont une classe CSS nommée "external"
$("a.external").click(function() {
alert("clic sur une ancre de style external");
});
});

Ainsi avec cet exemple tous les liens avec le style « external » dès qu’ils seront cliqués afficheront un message d’alerte.

Voici un exemple d’appel Ajax :

$.ajax({
type: "GET",
url: 'http://host.com/page.html',
success: function(content) {
// content est un parametre qui contient le code HTML de la page à l'url http://host.com/page.html
$("#content").html(content);
},
error: function() {
logInPage('Erreur de chargement Ajax de la page : http://host.com/page.html');
}
});

Le code $("#content") signifie que l’on sélectionne la balise avec l’identifiant content. La fonction html(« <a href...« ) signifie que l’on met dans la balise le code html en paramètre.

Ainsi si vous avez initialement dans votre page <div id="content">en cours de chargement ...</div>, après l’appel Ajax, le contenu de la page sera <div id="content"><h1>Titre1<h1>...</div> (où <h1>Titre1<h1>... est le contenu de la page à l’url http://host.com/page.html).

JQuery est un excellent framework, notamment grâce à une syntaxe bien pensée, mais qui exige quand même un certain coût d’entrée. Cependant, les exemples à disposition sont nombreux. De quoi réconcilier un certain nombre de développeurs Java avec le développement Web/Javascript.

Solution ORM en Javascript : Active Record JS

La société Aptana annonce la première version de Active Record qui permet d’utiliser une solution de mapping objet/relationnel (ORM) en Javascript en utilisant différents connecteurs :

• En mémoire, pour ne pas utiliser de base de données
• Google Gears (solution de persistance côté client)
• Adobe Air
• SQLite ou MySQL
• Des environnements compatibles HTML 5. Cette nouvelle version de HTML propose une spécification d’API de stockage côté client

Ce framework met en œuvre le pattern du même nom. Le pattern Active Record est un pattern souvent utilisé dans les frameworks Rails comme RubyOnRails, Django (Python) ou Grails (Groovy). C’est une approche pour lire les données d’une DB. Les attributs d’une table ou d’une vue sont encapsulés dans une classe.

Voici quelques opérations élémentaires qui peuvent être réalisées avec ActiveRecord JS :

// Connection en memoire (sans base de donnees)
ActiveRecord.connect(ActiveRecord.Adapters.InMemory);
// Creation du schema
ActiveRecord.execute('CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, ...
// Creation d'une entite
var jessica = User.create({
username: 'Jessica',
password: 'rabbit'
});
// Sauvegarde
jessica.save(); // ou jessica.synchronize()
// Recherche
User.findByUsername('Jessica');

Cependant ce n’est qu’une version béta, quelques problèmes d’implémentation subsistant, en particulier pour Internet Explorer.

Avec un tel framework, le client (navigateur) pourra fonctionner de manière plus détachée du serveur. D’une part, le client gèrera ses données propres indépendamment du serveur. D’autre part le client pourra sauvegarder et restaurer des informations dans le but de se re-synchroniser avec le serveur. Le client pourra gérer plus de traitement sans être lié au serveur, en quelque sorte en mode hors ligne (« offline »).

Pour plus d’informations vous pouvez consulter la page d’Active Record JS

Servlet 3.0 : une API innovante et convergente ?

L’API Servlet 3.0 vient de franchir le Public Review Ballot et nous pouvons aujourd’hui voir l’ampleur des innovations qu’apporte cette version. Les promesses de cette JSR concernaient principalement les applications RIA (introduction d’un mode asynchrone/comet) et l’intégration des frameworks web (accès programmatique à l’enregistrement des servlets et des filtres ou encore à la gestion des login et logout).
Si le manque de maturité des modes asynchrone et Comet pouvait rendre délicat leur standardisation, l’intégration des frameworks web semblait plus aisée étant donnée la longue expérience du monde Java sur ce sujet.

Hélas, on peut douter que Servlet 3.0 améliore réellement l’intégration de frameworks populaires comme SpringMVC, Struts2 ou encore Wicket. Cette pluggability passe d’abord par la possibilité de brancher un conteneur externe (comme Spring Framework ou Google Guice) pour instancier les composants de l’application (y compris les Servlet, les Filter et les ServletContextListener). Servlet 3.0 aurait pu mettre fin au monopole des conteneurs de servlets pour gérer le cycle de vie de ces composants, en introduisant une API de Service Provider Interface, qui permettrait d’utiliser un conteneur externe. Ces SPI sont fréquentes dans les API Java (cf JSF FactoryFinder, JAX-WS Provider, etc) et ont fait leurs preuves dans les frameworks web (Struts2 ObjectFactory, Wicket IWebApplicationFactory, etc).

A la place, Servlet 3.0 introduit un nouveau conteneur d’objets qui, s’il reprend les annotations standard @EJB, @Resource, @PersistenceContext, etc , n’en reste pas moins différent des déjà standards conteneur EJB, conteneur EJB Lite 3.1, conteneur de Managed Bean JSF ou encore du très probable conteneur de Web Beans.

L’enregistrement programmatique des Servlet et Filter (ServletContext#addServlet(...) et ServletContext#addFilter(...)) n’assouplit pas le monopole du conteneur de servlet sur le cycle de vie des Servlet et Filter : on enregistre les composants par leur nom de classe et le conteneur de servlet se charge de les instancier.

Par ailleurs, les annotations Servlet 3.0 (@WebServlet, @ServletFilter, @GET, etc), en plus de ne mutualiser ni le code, ni les concepts équivalents du très récent JAX-RS ( @Path , GET, etc), ont été beaucoup moins ambitieuses puisqu’on ne retrouve pas les QueryParam, PathParam, etc. de JAX-RS, qui existent pourtant depuis bien longtemps dans nos framework Web MVC (cf. Spring MVC @WebParam).

Ces limitations de la pluggability des frameworks web de Servlet 3.0 restreignent les perspectives de standardisation des frameworks web autres que JSF, pourtant si controversé .

En revanche, petit rayon de soleil, le support des modes asynchrone/Comet dans Servlet 3.0 semble satisfaire les projets innovants en la matière même s’ils vont sensiblement plus loin que la nouvelle API startAsync() (cf Grizzly and the New Atmosphere Comet Framework: Q&A with Project Lead Jean-Francois Arcand]).

Le coin de la technique

Sortie de FEST-Swing 1.0

Alex Ruiz nous informe sur son blog de la sortie de FEST-Swing en version 1.0.

Pour rappel FEST-Swing, tout comme UISpec4J, est un outil de test d’interface utilisateur pour une application Swing.

Ses principales caractéristiques sont :

• Support de tous les composants Swing standard (JDK),
• API de création et de maintenance des tests,
• Simulation de toutes les interactions utilisateur (souris, clavier…),
• Supporte les Applets,
• Ajout des captures d’écran des erreurs dans le rapport HTML,
• Utilisable avec JUnit et TestNG.

Une interface utilisateur devient alors aussi simple à tester que :

dialog.comboBox("domain").select("Xebia");
dialog.textBox("username").enterText("rmaton");
dialog.button("login").click();
dialog.optionPane().requireErrorMessage().requireMessage("Please enter your password");

Chaque classe de tests a la possibilité de définir les fonctions setUp et tearDown :

• setUp et tearDown en JUnit 3.8.x
• Toutes méthodes avec @After et @Before pour JUnit 4.x
• Toutes méthodes avec @AfterMethod et @BeforeMethod pour TestNG

On se retrouve avec des tests du type :

import org.testng.annotations.*;
import org.fest.swing.fixture.FrameFixture;
public class FirstGUITest {
private FrameFixure window;
@BeforeMethod
public void setUp() {
window = new FrameFixture(new MyFrame());
window.show(); // shows the frame to test
}
@AfterMethod
public void tearDown() {
window.cleanUp();
}
@Test
public void shouldCopyTextInLabelWhenClickingButton() {
// Your unit tests
}
}

La librairie se télécharge ici ou, pour notre pom adoré, dans ce repository.

Intégration Continue avec Maven

Brian Fox de Sonatype nous livre ses Maven Continuous Integration Best Practices pour faciliter l’Intégration Continue (IC) avec Maven :

• Laisser le server d’IC déployer automatiquement les snapshots pour s’assurer que le repository est synchro avec le système de gestion des sources. Nexus aide en purgeant automatiquement les snaphosts.
• Isoler les repository locaux des différents projets avec -Dmaven.repo.local=xxx pour éviter qu’un artifact buildé par un projet ne soit visible par les autres builds
• Purger régulièrement (tous les soirs) les repository locaux permet de garder l’espace disque sous contrôle
• Activer le mode Batch pour raccourcir les logs (skip les traces de téléchargement des dépendances) avec -B ou dans settings.xml :

false

• Activer les traces complètes -e pour débugger plus facilement
• Rediriger les erreurs des tests sur la sortie standard avec -Dsurefire.useFile=false ou dans settings.xml :

 true 

• Toujours chercher les snapshots avec -U ou dans settings.xml :

always

Nouvelle version de RichFaces: la 3.3.0 est sortie

4 mois après la dernière version (3.2.2), JBoss sort la version 3.3.0 de RichFaces.
Celle-ci a corrigé pas mal de bugs, la liste est disponible sur Jira. Ella a amélioré certains composants ou en a simplifié d’autres. Enfin, le support du navigateur Chrome a été revu et amélioré.

Deux nouveaux composants viennent s’ajouter aux nombreux déjà existants :

• l’éditeur WYSIWYG adapté de TinyMCE accessible par la balise <rich:editor>,
• l’amélioration du traffic Ajax grâce à une file d’attente, en utilisant la balise <a4j:queue>.

L’éditeur ne nécessite pas de code javascript supplémentaire, tout est paramétrable par les propriétés du composant. Et surtout, il est extensible, on peut ajouter ses propres plug-ins.

La file d’attente Ajax est la petite révolution de cette version. Ce qu’on reproche souvent à JSF, c’est de rendre difficile l’utilisation d’Ajax dans le cycle de vie JSF. Ce composant va mettre de l’ordre dans tout ça et ne laisser passer qu’une requête à la fois, les autres sont mises en attente. Il va aussi réduire la charge du serveur en combinant plusieurs requêtes si celles-ci sont similaires. Enfin, plusieurs files d’attente peuvent être définies pour une gestion plus fine des requêtes (Global default queue, View scoped default queue, View scoped named queue, Form-based default queue).

D’autre part, quelques nouvelles fonctionnalités sont venues enrichir plusieurs composants:

• le slider de nombre qui permet de changer une valeur en faisant glisser un curseur sur une ligne (<rich:inputNumberSlider>) peut être positionné verticalement,
• l’évènement « clic droit » (onRowContextMenu) a été ajouté sur les lignes d’un tableau et permet de faire apparaître des informations (<rich:dataTable>),
• l’élément d’un menu (<rich:menuItem>) peut être utilisé seul et ajouté directement dans la toolbar.

Comme toujours avec RichFaces, il est possible de voir à l’oeuvre les composants sur la page de démonstration.

Enfin, le souhait des utilisateurs va se réaliser, la prochaine version de RichFaces a pour objectif d’enrichir les possibilités de positionnement des composants dans une page.

LiquiBase 1.9 : Des améliorations bien utiles

Le mois dernier, un billet sur la refactorisation de base de données avait présenté LiquiBase dans sa version 1.8.1. Nous tenions donc à vous informer de la sortie d’une nouvelle version qui confirme la forte activité autour de cet outil.

Sans surprise, cette version 1.9.0 corrige son lot de bugs et améliore la validation dans le schéma XSD.

La fonctionnalité majeure de cette nouvelle release se trouve dans la balise <modifySQL>. Elle offre un mécanisme de modification du code SQL après génération par les balises standards. Cela permet d’ajouter des informations spécifiques à la base de données utilisée, comme « engine innodb » pour une base MySQL.
Là où, avant, on devait passer par du code SQL custom (<sql>), on va pouvoir rester sur les balises existantes et les modifier à notre guise.

D’autre part, une nouvelle balise (<stop>) permet, en développement, d’arrêter le traitement du fichier et d’aller regarder dans la base de données pour voir si tout se passe comme il faut.

Enfin, dans les versions précédentes, pour inclure d’autres fichiers, il fallait les énumérer un par un, à présent, il suffit d’indiquer un répertoire avec la balise <includeAll>. Il faut toutefois être prudent car l’ordre des fichiers est important et cette balise parcours la liste dans l’ordre alphabétique, une politique précise de nommage s’impose.

Pour rassurer certains qui penseraient qu’il vaut mieux attendre la version 2.0 qui sort généralement après la version 1.9, le responsable du projet LiquiBase précise que la version majeure n’est pas prévue dans l’immédiat et que les prochaines versions seraient 1.10, 1.11, etc.

Donc n’ayez crainte et allez-y.

Comparatif de performance entre JSF/Seam à Wicket

Peter Thomas nous propose dans son article Seam / JSF vs Wicket: performance comparison, un comparatif de performance entre une solution Seam/JSF et Wicket.

Il y a deux éléments intéressants dans cet article :

• Le resultat de l’étude : Wicket semble plus performant que Seam/JSF

En effet, Wicket a une empreinte moins grande que Seam/JSF :

• Wicket consomme moins de mémoire JVM
• Wicket charge moins de classes
• Wicket démarre plus rapidement. Le temps de démarrage n’est pas un critère primordial mais il est représentatif des performances globales et impacte le développement
• Wicket a de meilleurs temps de réponse sur les différents scénarii

• La méthode de test de performance.

Ce n’est pas une méthode formelle qui garantit le résultat de manière scientifique mais cela donne une tendance.
Les outils utilisés sont :

• Ant pour le scripting du benchmark
• JMeter pour réaliser les mesures de temps de réponses en injectant une charge
• Eclipse Memory Analyzer pour réaliser les mesures d’empreinte mémoire de la JVM

Le travail effectué peut être facilement étendu à d’autres frameworks. Il est en outre possible de réutiliser une partie des scripts du projet Google Code PerfBench.

Actualité éditeurs / SSII

• Sortie de VirtualBox 2.0

Agilité

• Martin Fowler à propos de Scrum

RIA

• ActionScript 3 vu par les programmeurs Java

Le coin de la technique

• Comparaison avec le code de Wicket à GWT
• Liste de question à se poser lors du choix d’un framework d’application de bureau

Evènements de notre communauté en France et à l’étranger

• Forum SOA 2008
• Soirée Groovy au Paris JUG ce Mardi 09 Septembre

Actualité éditeurs / SSII

Sortie de VirtualBox 2.0

Cette semaine est sortie la première évolution de VirtualBox depuis l’acquisition d’InnoTek par Sun en février dernier. Pour mémoire, VirtualBox est disponible sous licence GPL depuis janvier 2007 et se positionne comme concurrent sérieux à VMware, VirtualPC, QEmu ou Xen. Un tableau comparatif avec VMWare est d’ailleurs disponible sur le site officiel ou vous pouvez également y retrouver la liste des systèmes d’exploitation compatibles.

La principale nouveauté de cette version 2.0 est la gestion des hôtes 64 bits.

Autres nouveautés notables :

• L’interface a été refaite : montée de version de QT (QT4) améliorant l’intégration avec Gnome et utilisation de l’interface native sous Mac OS X
• Support Native Command Queuing améliorant les performances des disques durs SATA
• Structure permettant la collecte d’informations sur l’utilisation des ressources des machines virtuelles
• Nouveau système d’avertissement de mises à jour
• Nouveau kit de développement
• Compatibilité avec les images ‘Microsoft VHD’ utilisées par Virtual PC

Agilité

Martin Fowler à propos de Scrum

Martin Fowler est interviewé par Jacky Li d’InfoQ China sur Scrum et le futur de l’Agile. À retenir :

• L’adoption des méthodes agiles est particulièrement difficile à cause des changements de mentalité que cela implique. Beaucoup de monde se concentre sur les pratiques plutôt que sur la philosophie, ce qui aboutit généralement à l’échec de l’adoption.
• Les impacts de l’Agilité se sentiront dans plusieurs décennies. En comparaison, la Programmation Orientée Object – apparue il y a 40 ans – a mis 20 ans à devenir le courant principal, et encore même aujourd’hui le code est écrit en Java mais il n’est pas orienté Objet.
• La certification Scrum dure seulement 2 jours et le terme « certification » peut tromper. Comprendre l’Agilité reste un exercice qui nécessite plusieurs mois. Cependant, c’est un bon début pour apprendre car les formateurs Scrum connaissent vraiment leur sujet, ce qui n’est pas le cas dans beaucoup d’autres technologies, par exemple RUP ou CMM.

En conclusion, Martin acquiesce que ce qui importe n’est pas de savoir « si un projet est agile » mais plutôt « comment s’améliorer ».

RIA

ActionScript 3 vu par les programmeurs Java

Avouons-le, les interfaces graphiques n’ont jamais été la tasse de thé des équipes de développement Java. Les succès relativement limités de Swing, Awt le prouvent.

Aujourd’hui, c’est Flex qui tient la tête des RIA émergents.

Alors qu’en est-il de son appropriation par les équipes Java ? Pour InfoQ, Jack Herrington donne des pistes de comparaison.
Nous ne nous attarderons pas dans cette revue presse sur les différences syntaxiques, mais plutôt sur les similitudes (ou les divergences) structurelles.

• Les classes : les deux langages sont des langages objets. Ils utilisent tous deux des espaces de nommage et la notion de package. Les imports, les variables de classe, les notions de public / private, les constructeurs vides ou valués, et les méthodes de classe sont aussi au rendez-vous.
  Une différence cependant : les getters / setters des variables de classe sont des méthodes particulières et réservées. Elles ont leur déclaration propre et leur appel se fait de manière transparente (on appelle myClass.myProperty même si en fait c’est le getter de myProperty qui est appelé).
  Autre différence notable, à la manière de Swing, on peut déclarer un objet comme EventDispatcher : celui-ci lance alors des évènements (sur le changement d’une variable par exemple) qui peuvent être intercepté à plus haut niveau, par un mécanisme d’abonnement.
• Interface : nouvelle « facilité » offerte par l’AS, les interfaces peuvent comporter des « variables ». En effet, en déclarant des getters / setters dans les interfaces, on donne l’illusion d’accéder à des « variables » déclarées par l’interface.
  On a donc une syntaxe du type myInterface.myProperty (au lieu d’utiliser en java le _getMyProperty()_).
• Constantes : le mot clé final est remplacé par le mot clé _const_
• Variables statiques, Exceptions. Rien de notable
• Héritage : le mot clé abstract est remplacé par le mot clé virtual. Le principe est identique.
• Itérateurs : AS ne propose pas de conteneurs fortement typés, comme les Tree, les Map. Cependant, on peut utiliser le type Objet{} et itérer sur ses attributs, comme on le ferait sur les clés d’une Map.
• Expressions régulières : les expressions régulières sont interprétées dans le code AS. On peut les utiliser pour manipuler par exemple des chaînes de caractères (rechercher dans une chaînes , scinder une chaînes…)
• E4X : l’une des différences les plus notables à ce jour est l’intégration du Xml dans ActionScript. Le parcours ou l’écriture d’un fichier est vraiment intuitif, grâce à l’utilisation des fonctions d’itération ou conditionnelles « standard ».

En conclusion, passer de Java à ActionScript ne devrait pas représenter un traumatisme trop grand. Mais entre posséder les bases et posséder l’ensemble des subtilités du langage, il faut rester méfiant, et une nouvelle race de développeurs de haut niveau pur ‘Flex’ fera probablement bientôt son apparition.

Pour retrouver l’intégralité de cet article et ses nombreux exemples, rendez-vous sur InfoQ

Le coin de la technique

Comparaison avec le code de Wicket à GWT

Dans l’article Wicket and GWT compared with code, Peter Thomas compare deux technologies qui font parler d’elles depuis quelques temps : GWT (Google) et Wicket (Apache)

Il est vrai que ces deux technlogies ont des points techniques en commun :

• GWT et Wicket privilégient la programmation événementielle en Java (à la Swing) plutôt que la programmation déclarative (à la JSP ou JSF)
• Ils ont un modèle de composants (ensemble de Panels et de _Widgets_)
• Ils ont un modèle de composants extensibles

Cependant, ils se différencient sur plusieurs points :

• Lors de la phase de compilation, GWT analyse le code pour générer une interface Web en DHTML
• Wicket exécute le code Java pour construire les composants, lorsque l’application Web est déployée
• Wicket utilise le templating HTML et les Widgets pour faciliter la réalisation des pages. GWT utilise de manière intensive la technologie CSS.

Peter Thomas nous présente ses conclusions à travers 13 points :

1. Wicket nous permet un contrôle complet sur le rendu HTML. De manière générale, en GWT, pour avoir une maîtrise complète du rendu HTML il faut être un virtuose de la technologie CSS.
2. Il est vrai qu’en GWT, il existe une impedance mismatch entre le langage Java et Javscript (Reflexion, synchronized, …). Dans certains cas, on doit effectuer des contournements de programmation en Java pour pouvoir effectuer le traitement en Javascript.
3. En GWT différentes pratiques doivent être réfléchies, conçues et mises en place pour effectuer de manière élégante certaines implémentations, à l’image du binding dynamique dans une table
4. Il faut maitriser la technolologie CSS pour maitriser le rendu GWT , ce qui n’est pas toujours évident
5. Un point de différence important entre GWT et Wicket et la gestion des Layouts. Wicket gère en priorité les Layouts par le templating HTML tandis que GWT passe par des objets de son modèle de composants : Layout. Cependant, il reste possible dans GWT, de définir un Layout dans la page HTML est d’injecter N composants GWT dans les balises HTML de cette page (code GWT : RootPanel.get("slot1").add(button))
6. Le débogage en GWT n’est pas toujours évident car il est difficilement possible de voir les sources (view source dans le navigateur). Cependant, l’outil de développement GWTHost fonctionne bien et s’intègre très facilement à l’IDE Eclipse pour le débogage.
7. Une démonstration de la réutilisation du code est faite dans Wicket, qui est un de ses points forts. Des bonnes pratiques de conception sur des applications classiques peuvent être réutilisées pour l’interface graphique.
8. Une difficulté avec GWT est son fonctionnement au premier abord un peu déroutant : la génération de code DHTML à partir du code source Java. Il faut en être conscient et connaître toutes les conséquences (maîtrise des instances d’objets dans le code Java GWT).
9. Avec Wicket, la gestion des URLS bookmarkable demande un effort supplémentaire.
10. Il est évident qu’une compilation de source GWT est plus lente qu’une compilation de source Wicket. Cependant, ce critère n’est pas important mais révèle un aspect important actuellement négligé dans GWT : le packaging et l’organisation des sources, surtout lorsque GWT s’intègre dans un existant conséquent (avec par exemple des objets métiers éparpillés dans les différents projets de sources).
11. Grâce à GWT 1.5 et au support du langage 1.5, l’observation précédente peut être plus facilement gérée
12. Un avantage certain de GWT est le fait d’être déconnecté du serveur ce qui permet un gain important de performance à l’exécution. Cependant, le développement et debogage des appels distants n’est pas toujours intuitifs. Il faut aussi faire attention à l’intégration dans un existant avec une forte responsabilité graphique du serveur (JSP/Servlet). Par exemple, même si des efforts ont été entrepris par la communauté GWT (hibernate4gwt), pour intégrer des acquis dans cette nouvelle technologie GWT, il reste comme même des régressions dans l’intégration du client au serveur.
13. Il reste cependant difficile d’effectuer des tests unitaires sur les interfaces graphiques … on est trop proche du fonctionnel

Wicket et GWT ont fait le choix audacieux de choisir un langage familier pour le développement d’application Web en Java. C’est un énorme avantage. Il faut reconnaître que si GWT introduit de nouveaux problèmes du fait de ces choix techniques, il permet de produire des applications Web de manière très productive. Il permet à un développeur Java de produire des applications Web qu’il aurait eu énormément de mal à réaliser avec des technologies plus classiques (JSP, HTML, Javascript, …). GWT et Wicket permettent de populariser le développement pour les purs et durs du développement Java.

Liens connexes :
- Blog de Bruno Marchesson qui analyse de manière très critique et argurmentée GWT

Liste de question à se poser lors du choix d’un framework d’application de bureau

Geertjan Wielenga nous propose une liste de questions à se poser lors du choix d’un framework RCP.

Les questions sont regroupées par catégorie :

• Architecture : Niveau de scalabilité, de flexibilité ? Comment le framework s’intègre avec d’autres frameworks existant ?
• Liste de fonctionnalité : Est-ce que le framework prend en charge un maximum de plomberie pour lier les différentes couches de l’application ? Est-il facile d’étendre la liste des fonctionnalités ?
• Open Source : Est-ce que l’open source s’inscrit dans votre stratégie d’entreprise ? Est-ce que l’Open Source vous fait peur ?
• Communauté : La communauté de développeurs est-elle active ? Le framework a t-il été utilisé et epprouvé dans le cadre d’une application « réelle » ? Quels sont leurs retours d’expérience sur son utilisation ?
• Période d’apprentissage : Est-elle conséquente ? Si oui, est-elle contrebalancée par les gains qu’apporte le framework ? Existe t-il une formation ?
• Outillage : Intégration avec un IDE (niveau ? Quel(s) IDE ?) Y a t-il de la génération automatique ou aide à la complétion de code ?
• Documentation : Existe t-elle ? Est-elle à jour, complète ? Y a t-il des livres (combien) traitant du sujet ?
• Support : Évaluer la rapidité (en fonction de la communauté et de la documentation) de traitement d’une question ? Existe t-il une mailing-list, un forum, un help desk ? Des patchs sont-ils livrés ou la correction d’un bug doit-elle attendre une RC ?
• Future : Quel est l’avenir du framework ? Quelle est la stratégie long terme de la société investissant dans le framework ?

La catégorie Productivité (rapidité de développement ? Nombre d’écrans développés par sprint ?) pourrait compléter cette liste pour qualifier un framework.
Les questions étant assez génériques, cette liste d’interrogations ne se limite pas seulement au choix d’un framework d’applications de bureau, ce questions reviennent lors de la sélection d’autres types de framework (MVC, RIA…).

Evènements de notre communauté en France et à l’étranger

Forum SOA 2008

Pour la troisième année consécutive, le monde informatique organise le Forum SOA.
L’édition 2008 se tiendra le 9 octobre 2008 à Paris (à l’Eurosite George V) et a pour thème « Des processus et des hommes ».
Le programme est disponible sur le site de l’événement.

Soirée Groovy au Paris JUG ce Mardi 09 Septembre

Groovy est à l’honneur pour la rentrée du Paris JUG, avec les venues de :

• Guillaume Laforge, VP Technology chez G2One, qui va nous présenter Groovy, le langage dynamique pour la machine virtuelle Java qui permet d’accroître la productivité des développements
• Fabrice Robini architecte chez OCTO, qui va nous présenter le framework web Grails, basé sur Groovy, qui permet là aussi de bénéficier de l’apport de productivité de Groovy, et d’un maximum de « Convention over configuration »

Pour la description de la soirée et les inscriptions, c’est par ici.

Les mécanismes de templating

Avec Wicket, même le templating est très simple. L’implémentation du templating dans Wicket est très proche de la façon de faire de SiteMesh (au moins pour la partie HTML). La mise en œuvre se fait par des mécanismes d’héritage : Wicket nomme ceci le Markup Inheritance. Prenons un exemple concret.

J’ai une page de template qui va définir le header et le footer commun de mon site. Ensuite le body va varier selon les pages. Je crée donc un fichier HTML et la classe Java associée. Dans le fichier HTML, j’ai juste besoin de préciser où va s’insérer le contenu des fils en positionnant la balise .

Ce qui donne dans le fichier HTML du parent :

<html>
<head>
<wicket:head></wicket:head>
</head>
<body>
	<div id="header"><!-- Contenu du header --></div>
	<div id="body">
		<!-- Positionnement du contenu des fils -->
		<wicket:child />
	</div>
	<div id="footer"><!-- Contenu du footer --></div>
</body>
</html>

La balise <wicket:head> permettra plus tard d’ajouter des éléments (comme le titre de la page) dans le header de la page à partir des enfants. Cette zone est en quelque sorte une zone modifiable du template.

La classe Java (ParentPage.java) associée :

package test.view;
// import ...;
public abstract class ParentPage extends WebPage {
	private static final long serialVersionUID = 1L;
	public ParentPage() {
		super();
		createTemplateComponents();
	}
	protected void createTemplateComponents() {
		// Ajout des composants communs dans le header et le footer
	}
}

Pour les pages du fils, je vais, comme d’habitude en Wicket, définir le fichier HTML et la classe Java associée. La classe Java va hériter de la classe ParentPage (les composants ajoutés et gérés par la page parente seront donc ajoutés à ma page).

package test.view;
// import ...;
public class ChildPage extends ParentPage {
	private static final long serialVersionUID = 1L;
	public ChildPage() {
		super();
		createComponents();
	}
	protected void createComponents() {
		// Ajout des composants propres à cette page
	}
}

Pour ce qui est du fichier HTML, je dois encadrer le code HTML qui doit être inséré dans le code HTML du parent par la balise <wicket:extend>.

<html>
<wicket:head>
	<title>Page fille !</title>
</wicket:head>
<body>
<wicket:extend>
	<!-- Ajout ici du contenu spécifique du fils -->
	<h2 align="center">Hello dans le fils</h2>
</wicket:extend>
</body>
</html>

Cette fois-ci, dans le header de la page et entre les balises <wicket:head>, j’insère la balise <title>. Ce titre sera inséré dans la page finale rendue à l’utilisateur. De même, je peux ajouter des imports CSS ou JavaScript propres à la page fille.

Et voilà, tout ce que j’ajouterai dans la page parent apparaitra aussi dans les pages filles !

L’internationalisation

L’internationalisation se fait de la façon habituelle, c’est à dire via l’utilisation de fichiers properties nommés en fonction de la langue supportée. Avec Wicket, il est possible d’adjoindre à chaque composant (page, formulaire, composant ‘maison’) un fichier properties portant le même nom et situé dans le même package que la classe associée.

Exemple : Le fichier properties contenant les traductions pour la page fr/xebia/wicket/demo/HomePage.java doit être fr/xebia/wicket/demo/HomePage.properties (par défaut bien sûr).

L’accès aux traductions se fait de trois manières :

• Dans le code HTML, en ajoutant la balise <wicket:message key= »stringKey » />
• Dans le code Java, en utilisant un type de modèle particulier : le StringResourceModel. Ce modèle peut être passé en paramètre de tous les composants Wicket (Label, TextField, etc)
• Toujours dans le code Java, en appelant la méthode getLocalizer().getString() sur n’importe quel composant.

Cependant, Wicket ne s’est pas arrêté là. Pour la classe StringResourceModel, la clé passée en paramètre peut être dynamique. Exemple : « product.${product.id} ». Le modèle passé en paramètre permet de résoudre la clé (dans ce cas, l’objet Product contient un champ id).

L’autre particularité, ici, réside dans le mécanisme de recherche de la traduction. Wicket va utiliser la hiérarchie de classes pour parcourir les fichiers properties.

Prenons en exemple la hiérarchie suivante :

+ fr/xebia/wicket/BasePage.java
+ fr/xebia/wicket/MyPage.java

Si dans la classe MyPage (ou la page HTML correspondante), je recherche une traduction, Wicket va rechercher la valeur en parcourant dans cet ordre les fichiers properties :

• fr/xebia/wicket/MyPage.properties
• fr/xebia/wicket/BasePage.properties
• org/apache/wicket/markup/html/WebPage.properties
• Et ainsi de suite, en remontant la hiérarchie de classe …

Pour les cas où cette façon de faire implique trop de duplication de properties, il est aussi possible de charger arbitrairement des fichiers properties dans la classe principale de l’application) en configurant les IResourceSettings.

Modifier dynamiquement les attributs des balises HTML

Le cas d’usage typique pour ce genre de besoin est la modification dynamique de l’attribut « class » d’un tag HTML pour modifier le rendu en jouant avec les CSS. Un autre type d’utilisation est d’écrire un appel JavaScript dynamique en définissant par exemple l’attribut « onClick » d’un bouton.

Différentes approches sont proposées dans cette page du Wiki mais nous n’en retiendrons ici qu’une seule. Il s’agit d’utiliser la classe AttributeModifier. Cette classe est très simple dans son usage : on ajoute une instance de cette classe à n’importe quel élément Wicket héritant de Component comme suit :

TextField textField = new TextField("myField", new Model());
textField.add(new AttributeModifier("class", true, new Model("formFields")));

Dans cet exemple, un attribut « class » sera ajouté même s’il n’est pas présent dans le HTML (signification du paramètre « true »). La valeur de l’attribut est donnée par le modèle passé en 3ème position.

Il est aussi possible de modifier le comportement par défaut en surchargeant la méthode getObject() :

textField.add(new AttributeModifier("class", new Model() {
   public Object getObject(final Component component) {
         String cssClass;
         if ( test.getAlarmState() )
             cssClass = "alarm";
         } else {
             cssClass="noAlarm";
         }
         return cssClass;
   }
 }));

C’est tout pour cette fois. Vous en savez déjà assez pour commencer votre nouveau projet avec Wicket. D’autres aspects de Wicket sont à découvrir : avec Wicket, on peut aussi faire de l’AJAX, des tests d’IHM et plein d’autres choses.

A l’occasion de ces articles, un projet de démonstration de wicket a été créé et est disponible (sous License Apache 2.0) sous le projet xebia-france hébergé chez GoogleCode. Voici le lien direct vers le repository Subversion.

Enfonçons-nous un peu dans les mécanismes du framework. Cette semaine, étudions la gestion de la session, la validation de formulaires et l’intégration (toujours aussi simple) avec SpringFramework.

La gestion de la session

Le framework s’occupe déjà de mettre en session la page courante et les composants Wicket inclus dans celle-ci. Ce mécanisme permet notamment d’écrire les traitements de réponse aux événements à la Swing (onClick, onSubmit). Il est cependant très important de faire attention aux objets que l’on met en attribut des pages et composants pour éviter de voir grossir la taille de la session.

Mais Wicket ne met en session que la page courante. Or, dans bien des cas, il est nécessaire de pouvoir accéder et manipuler des données de la session afin de rendre certaines données accessibles au travers d’un enchainement de pages. Wicket nous permet bien sûr d’accéder à la session mais nous oblige à le faire proprement.

A partir de n’importe quel composant, il est possible d’obtenir la session en utilisant la méthode getSession() qui renvoit un objet Session, wrapper Wicket de la véritable session HTTP. On s’empresse donc de regarder les méthodes de cette session et on s’aperçoit que les méthodes get/setAttribute() sont « protected » et donc inaccessibles. Comment faire donc ?

Wicket nous invite en réalité à hériter de la classe WebSession pour proposer des méthodes explicites pour manipuler la session. L’avantage de cette méthode est la lisibilité et la limitation des erreurs dues à la manipulation de la session via les méthodes génériques habituelles et des clés de type String. Voici donc un exemple de session personnalisée :

public class ShoppingWebSession extends WebSession {
	private static final long serialVersionUID = 1L;
	private static final String CART_KEY = "cart";
	public XkeWebSession(Request request) {
		super(request);
	}
	public void setCart(Cart cart) {
		setAttribute(CART_KEY, cart);
	}
	public Cart getCart() {
		Cart cart = (Cart) getAttribute(CART_KEY);
		return cart;
	}
}

Ensuite, il faut dire à Wicket d’utiliser cette classe de session à la place de celle par défaut. Souvenez-vous de la classe principale dont je vous ai parlé dans un précédent article. C’est dans cette classe que nous allons redéfinir la classe qui représentera la session. Il suffit de redéfinir la méthode newSession(Request, Response) de la classe Application pour proposer notre classe de session.

@Override
public Session newSession(Request request, Response response) {
	return new ShoppingWebSession(request);
}

Et voila ! Wicket utilisera désormais votre classe pour gérer la session HTTP.

La bonne nouvelle, ce genre de ligne disparait de notre code :

((Cart) request.getSession().getAttribute("cart"));

La mauvaise, lors de l’utilisation de notre session, il faut effectuer un « cast » :

((ShoppingSession) getSession()).getCart();

Malgré cela, l’accès à la session ne se fait plus via des String mais au travers de méthodes Java qui doivent compiler, ce qui évite bien des erreurs.

Il est aussi possible d’utiliser des Helpers ou de créer une base de composants fournissant des méthodes pour accéder sans « cast » à la session.

La validation de formulaire

En ce qui concerne les champs requis, la procédure est très simple : on les définit avec la méthode setRequired(boolean) disponible sur la classe FormComponent (dont héritent quasiment tous les champs de formulaire).

TextField textField = new TextField("myRequiredField", new Model());
textField.setRequired(true);

Pour la validation plus avancée de valeur, il faut utiliser les validators qui implémentent l’interface IValidator. On ajoute ensuite aux éléments du formulaire les validations nécessaires avec la méthode add(IValidator). Wicket fournit en standard quelques validators disponibles dans le package org.apache.wicket.validation.validator (email, date, number, string, etc). Il est bien sûr possible de créer ses propres validateurs en implémentant soi-même l’interface IValidator.

Exemple :

TextField textField = new TextField("myRequiredField", new Model());
textField.add(NumberValidator.range(10L, 99L)); // Valide un entier compris entre 10 et 99

Pour effectuer des validations entre les éléments du formulaire (par exemple, si tel champ vaut telle valeur alors tel autre champ doit ….), il faut se tourner cette fois-ci vers l’interface IFormValidator ou la classe AbstractFormValidator. Quelques implémentations de base sont disponibles mais ce genre de validation reste très spécifique aux besoins de l’application.

Encore une fois, pas de fichier XML fastidieux à définir, juste du bon vieux Java :-) .

Intégration avec SpringFramework

Pour utiliser Spring avec Wicket, il faut ajouter l’extension wicket-spring et wicket-spring-annot à votre projet en ajoutant la dépendance dans votre pom.xml.

Du point de vue de la configuration Spring, il suffit de déclarer la classe principale de l’application en tant que bean avec un scope singleton.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	default-autowire="no"
	xsi:schemaLocation="
	http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
	<bean id="wicketApplication" class="fr.xebia.view.WicketApplication" scope="singleton"/>
	<!-- Définition des autres beans -->
	[.........]
</beans>

On modifie le Servlet Filter dans le web.xml, en spécifiant cette fois-ci, la propriété « applicationFactoryClassName ». Cette propriété pointe vers la factory Spring qui permet l »intégration des deux frameworks :

<filter>
	<filter-name>Application</filter-name>
	<filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class>
        <init-param>
            <param-name>applicationFactoryClassName</param-name>
            <param-value>org.apache.wicket.spring.SpringWebApplicationFactory</param-value>
        </init-param>
</filter>

Puis dans la méthode init() de la classe principale de l’application (rappelez-vous celle qui hérite de WebApplication), il faut ajouter une ligne pour que l’injection de dépendance fonctionne pour les pages Wicket :

addComponentInstantiationListener(new SpringComponentInjector(this));

Ce SpringComponentInjector va utiliser la classe WebApplicationContextUtils de Spring pour retrouver le contexte Spring (ceci sous-entend que vous ayez configuré un ContextLoaderListener Spring dans le web.xml par exemple pour charger la déclaration des beans gérés par Spring). Si vous voulez charger le contexte Spring vous-même, il est aussi possible de passer le contexte Spring en paramètre du constructeur de SpringComponentInjector.

Enfin dans le code Java, il nous suffit d’ajouter l’annotation @SpringBean devant les attributs des composants (Page, Form, etc.) pour lesquels il faut injecter des beans gérés par Spring.

@SpringBean(name="mySpringService")
private MyService myService;

Et voila, rien de plus !

La prochaine fois, nous verrons la mise en œuvre des mécanismes de templating, l’internationalisation ainsi que la façon d’écrire des tests unitaires (ce qui tient à cœur aux équipes de Xebia) !

Dans le précédent billet, nous nous étions arrêtés à la mise en place d’un projet Wicket. Aujourd’hui, regardons de plus près la construction des pages et la façon d’implémenter la logique de navigation avec les formulaires et les liens.

Construction des pages

La construction des pages se fait en deux étapes :

• Création du fichier HTML
• Création de la classe Java correspondante

Par défaut, Wicket suppose que le fichier HTML et la classe Java doivent être dans le même package et porter le même nom (sauf l’extension bien sûr) . Il est cependant possible de modifier ce comportement.

Le fichier HTML utilise exclusivement la syntaxe HTML sur laquelle on vient positionner des attributs "wicket:id" pour les éléments qui sont associés aux traitements métiers des pages. Les balises auxquelles on ajoute cet attribut représentent le contenu dynamique (que l’on veut traiter en Java). C’est par cet attribut que Wicket fera la correspondance entre les tags HTML et les composants créés en Java. Le code HTML ne contient rien d’autre que de la mise en page et mise en forme (classique HTML + CSS), la logique métier étant complètement implémentée en Java. Un bel exemple de "Separation of concerns".

Etudions un exemple pour bien comprendre ce mécanisme.

Imaginons le fichier HTML suivant avec un message que l’on veut dynamique, un champ texte et un bouton :

<html>
  <body>
    <p>Dynamic Message goes here</p>
    <form>
    	<input type="text" />
    	<input type="submit" value="update"/>
    </form>
  </body>
</html>

Le passage à Wicket donnera :

<html>
  <body>
    <p wicket:id="message">Message goes here</p>
    <form wicket:id="messageInputForm">
    	<input type="text" wicket:id="messageInput"/>
    	<input type="submit" value="update"/>
    </form>
  </body>
</html>

On ajoute l’attribut wicket:id auquel on donne une valeur unique qui nous servira dans le code Java. Cet attribut "wicket:id" persiste par défaut dans le HTML même après traitement par Wicket. Il est cependant possible de demander à Wicket de supprimer ces attributs (voir ici) en production pour obtenir des pages HTML conformes au standard du W3C.

Il nous reste plus qu’à écrire la classe Java correspondante qui doit hériter de la classe WebPage :

public class HelloWorld extends WebPage
{
  public HelloWorld()
  {
    IModel messageModel = new Model("Hello World!");
    add(new Label("message", messageModel));
    add(new MessageForm("messageInputForm", messageModel));
  }
  private static final class MessageForm extends Form
  {
    public MessageForm(String id, IModel model)
    {
      super(id);
      add(new TextField("messageInput", model));
    }
    protected void onSubmit()
    {
      // Rien à faire ici, le modèle sera automatiquement mis à jour
    }
  }
}

On remarque que le code Java réutilise les ids qui apparaissent dans le code HTML. C’est via ces ids que le pont entre le Java et le HTML est fait.

Ensuite, la seconde chose que l’on note est l’imbrication des composants. Cette imbrication doit respecter celle qui existe dans le HTML. Ainsi puisque le formulaire contient le champ texte, dans le code Java, on doit retrouver cette contenance.

L’autre particularité à remarquer est l’utilisation de l’objet Model. Tous les composants Wicket ont un model qui permet de définir leur contenu : même un simple label utilise un Model pour afficher son body. Chacun des modèles doit implémenter l’interface IModel (voir paragraphe suivant).

Dans notre cas, le champ texte et le label partagent le même modèle. Ainsi, le contenu du label aura le même contenu que le champ texte. De plus, par défaut, la soumission d’un formulaire entraîne la mise à jour automatique du modèle avec les données du formulaire. La classe Form appelle simplement la méthode setObject(…) du modèle avec la donnée correspondante du formulaire. La mise à jour du champ causera donc la mise à jour du label après soumission du formulaire. Il est bien sûr possible d’ajouter des traitements dans la méthode onSubmit() du formulaire.

Je vous invite à faire un tour dans les exemples, la Javadoc et le wiki pour éplucher les différents composants et leur modèle respectif.

La notion de Model

Les composants Wicket reposent tous sur un modèle. Les composants accèdent aux données qu’ils doivent prendre en charge via le modèle qui leur est attaché. Ces modèles implémentent tous l’interface IModel. Ceci permet de garder le contrôle sur l’accès aux données par les composants. Il est à noter que les objets qui implémentent cette interface seront systématiquement stockés dans la session. Il faut donc faire attention à la façon dont nous implémentons les modèles pour éviter de surcharger la session.

Plusieurs modèles sont disponibles et fournis par Wicket :

• Basic Models – Pour implémenter un modèle basique qui sera intégralement stocké dans la session. Pour implémenter ce modèle, vous pouvez utiliser simplement la classe Model.
• Detachable Models – Ces modèles implémentent l’interface IDetachable et offrent la méthode detach(), qui permet d’être notifié quand Wicket n’a plus besoin du modèle, ainsi les données peuvent être libérées de la mémoire au plus tôt.
• Nested Models – Les modèles peuvent aussi être imbriqués pour représenter une hiérarchie d’objets. Pour ce faire, il suffit d’implémenter la méthode getNestedModel() de l’interface IModel qui renvoie le modèle sous-jacent.
• Property Models – La classe AbstractPropertyModel fournit un comportement par défaut pour les modèles basés sur des propriétés. La classe PropertyModel permet d’encapsuler un POJO et de donner accès aux propriétés de cet objet. C’est cette classe qu’on utilise pour associer l’attribut d’un objet à un champ de formulaire.
• Compound Property Models – Ce type de modèle permet de changer le comportement du modèle en fonction du composant qui y accède. Les méthodes get et setObject prennent le composant en paramètre pour cela.

Le PropertyModel et le Model restent les deux modèles les plus courants.

Exemple : 

Label myLabel = new Label("myLabel", new Model("Hello world !"));
Person person = .... // Obtenir un objet Person
TextField myTextField = new TextField("myTextField",
	new PropertyModel(person, "name"));

La navigation dans Wicket

Avec Wicket, la navigation se code en Java. Ici, pas de fichier xml de configuration des mappings URL/Class. Une méthode principale est utilisée pour ceci, il s’agit de setResponsePage() disponible sur la classe Component. Cette méthode prend en paramètre soit une classe, soit une classe avec des paramètres, soit une instance de page (dans les deux cas, la classe passée en paramètre doit hériter de la classe Page).

• setResponsePage(Class) permet de rediriger vers une page indépendante des données de la page courante. L’instanciation de la page et la gestion de son cycle de vie sont effectuées par Wicket.
• setResponsePage(Class, PageParameters) redirige vers une page en lui passant des données. L’instanciation de la page et la gestion de son cycle de vie sont là aussi effectuées par Wicket.
• setResponsePage(Page) La troisième (avec une instance de page passée en paramètre) permet de pointer vers une page que l’on aura instanciée nous-même et à laquelle on a passé des paramètres.

setResponsePage(MySecondPage.class);
setResponsePage(new MySecondPage(myTextField.getModel())); // On passe des données dynamiques à la page cible

Nous allons appeler cette méthode en répondant aux "événements" de l’application à la manière d’une application Swing (onClick, onSubmit, etc.) ou en spécifiant pour certains types de lien, la page à afficher en cas de click.

Il y a deux principaux moyens de naviguer dans Wicket :

• les formulaires : Dans ce cas, on utilise (ou hérite de) la classe Form à laquelle on ajoute les composants du formulaire. Le traitement associé à la validation du formulaire est codé dans la méthode onSubmit(). C’est aussi dans cette méthode que l’on peut définir la page qui sera affichée après soumission du formulaire via la méthode setResponsePage().

/**
 * @see org.apache.wicket.markup.html.form.Form#onSubmit()
 */
public final void onSubmit() {
	// Do the submit stuff (update the database, etc.)
	setResponsePage(MySecondPage.class);
}

• les liens : Les liens héritent en général de la classe Link qui fournit les mécanismes de base pour créer un lien. Pour définir l’action à effectuer lors d’un click, on redéfinit simplement le méthode onClick(). On peut effectuer dans cette méthode un traitement pour finir par donner la page à afficher en résultat via la méthode setResponsePage(). Il est aussi possible d’utiliser la classe PageLink qui redirige simplement vers une page donnée en paramètres.

Link addToCartLink = new Link("addToCartLink") {
	private static final long serialVersionUID = 1L;
	public void onClick() {
		AddToCartPage page = new AddToCartPage(book.getId());
		setResponsePage(page);
	}
};
 // ou
new PageLink("viewLink", ViewPage.class);

Par défaut, les liens ne peuvent être ajoutés aux favoris (si on retourne sur une page "bookmarkée", on obtient un message "Page expired"). Les liens sont en fait maintenus en session, ce qui explique la possibilité de créer ses liens en Java de cette façon. Pour créer un lien "bookmarkable", il faut utiliser la classe du même nom : BookmarkablePageLink. Ce type de lien peut être ajouté aux favoris.

C’est tout pour cette fois, il vous faudra un peu de patience avant d’en savoir plus sur les fonctionnalités de Wicket.

Dans cette première partie, nous verrons comment démarrer avec Wicket.

Quickstart

Démarrer avec Wicket est plutôt simple. Il suffit de lancer une commande Maven2, ce qui a deux avantages :

• Générer automatiquement un pom avec les dépendances Wicket
• Générer un squelette de projet Wicket

Il existe donc un archetype Wicket pour Maven2 que l’on peut utiliser comme suit :

mvn archetype:create -DarchetypeGroupId=org.apache.wicket
-DarchetypeArtifactId=wicket-archetype-quickstart
-DarchetypeVersion=1.3.0-rc1
-DgroupId=com.mycompany
-DartifactId=myproject

Qu’obtient-on d’intéressant avec cet archetype ?

• Un fichier pom.xml
• Un fichier webapp\WEB-INF\web.xml préconfiguré pour Wicket
• Quelques fichiers sources dans src\main\java\com\mycompany :
  - Une page d’accueil constituée d’un fichier HTML (HomePage.html) et d’un fichier Java (HomePage.java)
  - Une classe Java (WicketApplication.java)
• Une classe Java src\test\java\com\mycompany\Start.java qui permet de lancer Jetty

Vous avez déjà une application Wicket fonctionnelle à ce stade.

Ensuite, générer la configuration Eclipse avec la commande :

mvn eclipse:eclipse

(Attention, le plugin maven eclipse n’est pas encore compatible WTP 2.0, c’est la version de WTP livrée dans Eclipse Europa, pour avoir ce support, il faut compiler le plugin maven eclipse 2.5-SNAPSHOT, en attendant sa sortie officielle.)

Configuration de l’application web

Revenons sur certains des fichiers générés par l’archetype Maven2. Pour utiliser Wicket dans une application web, il faut ajouter quelques lignes dans le web.xml. On y référence en fait un simple Servlet Filter qui lui-même pointe vers une classe de l’application.

<filter>
<filter-name>wicket.myproject</filter-name>
<filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class>
<init-param></init-param></filter>
<param-name>applicationClassName</param-name>
<param-value>com.mycompany.WicketApplication</param-value>
<filter-mapping>
<filter-name>wicket.myproject</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

C’est tout pour la configuration en XML. Le reste des développements se fera en HTML et en Java !!

La pièce maîtresse

Le Servlet Filter pointe vers la classe principale de l’application qui doit hériter de WebApplication. C’est le point d’entrée de l’application Wicket. Cette classe permet :

• de configurer l’application en utilisant les nombreuses méthodes de type getXXXXSettings() (où XXXX peut être remplacé par Session, Markup, Framework, Resources, Security, etc.).
• de définir la page d’accueil en surchargeant la méthode getHomePage() :

import org.apache.wicket.protocol.http.WebApplication;
public class HelloWorldApplication extends WebApplication {
public void init() {
// getXXXSettings().set ......
}
/**
* @see org.apache.wicket.Application#getHomePage()
*/
public Class getHomePage() {
return HelloWorld.class;
}
}

Cette « HomePage » sera affichée, par défaut, lorsqu’un utilisateur accédera à l’application sans adresser directement une page visible de l’application (nous reviendrons sur ce point dans les articles suivants).

Et voilà, la magie Wicket vient d’opérer : vous avez déjà une application exécutable. Pour la tester, c’est encore très simple.

Le pom Maven2, généré par l’archetype Wicket, est configuré pour pouvoir lancer jetty avec l’application web.

Démarrer le serveur Jetty (préconfiguré lui aussi dans le POM généré) via :

mvn jetty:run

Ouvrez votre navigateur à l’adresse http://localhost:8080/myproject. Vous verrez apparaître votre première application Wicket .

A bientôt, pour de nouvelles aventures avec Wicket …

Actualité éditeurs / SSII

• Sortie de Wicket 1.3.1
• Sortie de Grails 1.0

Agilité

• Comment mesurer le succès d’un projet agile du point de vue client ?

Le coin de la technique

• Eclipse 3.4 M5 : le Breadcrumb Mode
• Les différents GC de la JVM
• Test Unitaire avec Spring MVC
• Websphere Webcast : Prepare for Problem Determination for WebSphere Application Server

Actualité éditeurs / SSII

Sortie de Wicket 1.3.1

Il y a un mois nous annoncions la sortie de Wicket 1.3.
Comme un peu de teasing ne fait pas de mal, nous profitons de la sortie version 1.3.1 pour vous annoncer une prochaine série de billets dédiée à ce Web Framework.
Quant à cette version, la principale nouveauté concerne le support transparent et out-of-the-box d’un mode cluster.

Sortie de Grails 1.0

Grails est défini comme ‘the ultimate rapid prototyping for Java’ par certains. Il s’agit d’un framework web s’inspirant de Ruby on Rails écrit en Java et de Groovy. Grails repose sur des frameworks ayant fait leurs preuves comme Spring et Hibernate.
Vous pouvez télécharger Grails à cette adresse, sa documentation est disponible ici.

Agilité

Comment mesurer le succès d’un projet agile du point de vue client ?

Vikas Hazrati revient dans InfoQ – Discussion: Measuring Success of an Agile Project from the Customer’s Perspective sur un échange ayant eu lieu sur le user group Scrum Development.
Il y offre des pistes pour définir quels éléments de mesure peuvent (devraient) être communiqués par l’équipe afin qu’un client puisse mesurer sa satisfaction (et donc le succès du projet).

Le coin de la technique

Eclipse 3.4 M5 : le Breadcrumb Mode

Le projet Eclipse vient de mettre à disposition le MileStone 5 de la version 3.4 – Projet Ganymede (Date de Sortie prévue le 25 juin). Parmi les évolutions marquantes, on peut noter le Breadcrumb Mode. Une fois activé, Eclipse ajoute sur chaque fichier ouvert une barre de navigation horizontale qui indique les différents éléments qui mènent à la sélection courante. Dans cette vidéo, on voit l’évolution de cette barre en fonction de la sélection: une classe, une méthode, une inner-classes et une méthode de l’inner-classe.

Démonstration en vidéo : Breadcrumb.wmv.

Les différents GC de la JVM

Ce post de Jon Masamitsu présente les particularités des différents algorithmes offerts par la JVM pour gérer et libérer les différentes zones mémoires d’une JVM Sun. Il dévoile également un nouveau type de ‘collector’ qui serait disponible et utilisé par défaut dans la prochaine version de Java, le ‘Garbage First’ ou G1. L’idée principale est ne plus diviser la mémoire en deux zones (Young & Tenured) mais en plusieurs régions dont le rôle majeur (Young/Tenured) serait déterminé au runtime.

Test Unitaire avec Spring MVC

Le nombre de tests unitaires d’un framework de présentation est souvent faible en comparaison des autres parties de l’application. C’est sur ce constat que le framework Spring MVC a mis l’accent sur l’outillage de ces tests unitaires.
Craig Walls et John Ferguson Smart nous présentent respectivement leurs conseils dans Unit-testing Spring MVC: It gets even awesomer et Unit testing your Spring-MVC applications. Il n’y a plus d’excuses !

Websphere Webcast : Prepare for Problem Determination for WebSphere Application Server

Yu Tang, membre du WebSphere SWAT team, nous présente Prepare for Problem Determination for WebSphere Application Server . Les points essentiels :

• La gestion d’un problème sur un serveur J2EE se décompose en trois étapes :
     - Collecte des informations de diagnostique. Cette phase est essentielle pour la correction sur le fond du problème.
     - Fix en urgence et redémarrage du serveur.
     - Correction sur le fond du problème.
• Les problèmes se regroupent en deux grandes familles :
     - Les crashs (JVM, système, etc).
     - Les blocages / dégradations de performances (avec ou sans consommation élevée de CPU).
• Les principales informations à collecter sont :
     - Les classiques logs SystemOut et SystemErr sans oublier les informations de FFDC et d’activity.log.
     - Les logs de VerboseGC : un très bon indicateur de l’état de santé de la JVM. VerboseGC mérite d’être activé en permanence car son impact sur les performances est très faible (il faut toutefois gérer la purge régulière du fichier).
     - Les javacores (aka thread dumps) : essentiels pour diagnostiquer les blocages/dégradations de performances.
     - Vmstat et netstat : compléments des javacores en cas de problème de performance.
     - Les heap dumps : essentiels pour traiter les OutOfMemoryError. Préciser la variable IBM_HEAPDUMPDIR pour diriger ces logs très volumineuses sur un système de fichiers dédié pour prévenir les problèmes file system full [1].
     - Il faut rédiger et tester régulièrement les procédures de collecte des informations de diagnostiques (notamment les heap dumps et les java cores).

Un complément pour approfondir le sujet : The Support Authority: 12 ways you can prepare for effective production troubleshooting par IBM Software Services for Websphere.

[1] Ce système de fichiers dédié (e.g. /coredumps/) sera mutualisé entre les différentes applications java voire avec d’autres applications qui peuvent générer des cores volumineux. Ce système de fichiers est destiné à devenir plein si le problème se répète rapidement et que le nombre de cores se multiplie. Son but est d’éviter de remplir les autres systèmes de fichiers.

Les modes d’échanges sont variés :

• De la présentation formelle courte mais intense. Exemple : Google Web Toolkit ; Les ESB (Enterprise Services Bus) ou Migration WebLogic/JBoss.
• A des sessions de travaux pratiques de plusieurs heures où chaque consultant peut aller au fond choses sur un sujet technique. Exemple : Maven 2.0 ; OSGi ou WebSphere ObjectGrid.
• En incluant des débats (Exemple : Les EJB ont-ils un avenir?) ou des concours sur une journée (Exemple : Web Framework Contest).

A partir du mois de Février 2008, les XKE sont ouverts à l’ensemble des personnes à l’écoute du marché de l’emploi autour des technologies Java/J2EE. Si vous êtes l’une d’entre elles, n’hésitez pas à contacter Mélanie Bacrot pour vous inscrire et connaître les dates des prochaines sessions. L’agenda sera publié, tous les mois, sur ce blog.

Au programme du XKE de février 2008 :

Actualité éditeurs / SSII

• Oracle rachète BEA

Agilité

• Mike Cohn donne des pratiques d’adoption des méthodes agiles

RIA

• Qu’est-ce que Flex ?

SOA

• JEE 6 : Extensibility, Profiles and Pruning

Le coin de la technique

• Une expérience positive sur Wicket

Actualité éditeurs / SSII

Oracle rachète BEA

Massimo Pezinni du Gartner Group expose son point de vue dans un article paru sur LMI : il voit dans ce rachat un danger de disparition de composants BEA hors WLS et Tuxedo.
Selon lui le projet Fusion est déjà bien engagé chez Oracle et l’arrivée de BEA ne devrait pas changer la donne. Il parle de certains produits qui passeraient en mode maintenance … De là à s’interroger sur l’avenir des produits nouveaux (ALSB, WLI) il n’y a qu’un pas.
Effectivement, en quelques années la gamme des produits BEA s’est considérablement élargie. On distingue 3 gammes :

• La gamme historique : Tuxedo.
• La gamme infrastructure WebLogic-* : Weblogic Server, WebLogic Integration, Weblogic Portal et JVM JRockit
• La gamme SOA : Aqualogic-* : ALSB, ALDSP,ALBPM, ALRR, ALES, ALUI, …

Il faut regarder ce qui est à ce jour massivement vendu chez les client BEA : Weblogic Server, Tuxedo, WLI/WLP, ALSB.

• Oracle est certainement très intéressé par Weblogic Server qui est reconnu comme l’un des meilleurs serveurs d’applications.
• WLI est sûrement le produit qui peut résister et continuer à exister s’il est vu comme un outil d’intégration et non comme un moteur de BPM.
• Concernant ALUI, ex Plumbtree, il y a un gros parc installé. Il faut savoir que ALUI est globalement indépendant du serveur d’application. Pour une réflexion sur les portail BEA/Oracle, vous pouvez lire le billet de Chris Bucchere : One Portal to Rule Them All.
• De son côté, Tuxedo n’évolue pas énormément. Il est déjà en mode maintenance depuis des années mais avec un parc client énorme.
• JRockit sous Linux devrait également être conservé. C’est une excellente JVM, plus performante que celle de Sun qui concentre plutôt ses optimisations sur la version Solaris (rien d’étonnant à celà). Ce produit est également un vitrine pour BEA où il démontrait son savoir faire technologique. Si l’investissement annuel est raisonable, Oracle pourrait bien conserver cette vitrine.
• ALSB (AquaLogic Service Bus), l’ESB de BEA pourrait quant à lui résister car déjà bien vendu et reconnu.

Pour tout le reste, l’avenir semble plus sombre : peu de clients et en doublon avec une offre déjà existante chez Oracle (c’est quand même Oracle qui rachète BEA, et pas BEA qui rachète le département middleware d’oracle).

Agilité

Mike Cohn donne des pratiques d’adoption des méthodes agiles

Mike Cohn, membre fondateur de l’Agile Alliance, donne quelques pistes sur la façon d’injecter des pratiques agiles dans une entreprise à travers des patterns de base.

• Faut-il démarrer l’agilité sur un petit projet, ou transformer toute l’organisation d’un coup?
• Faut-il d’abord mettre en place les pratiques techniques XP ou d’abord s’efforcer de développer par itérations, sans mettre en place TDD (Test Driven Development), pair programming ou intégration continue?
• Faut-il mettre en place l’agilité en « mode furtif », ou faut-il en faire la publicité à travers toute l’entreprise et même en dehors?

Comme toujours, il faut être pragmatique! Et choisir suivant le contexte les pratiques qui s’adaptent le mieux à l’entreprise.

RIA

Qu’est-ce que Flex ?

Ted Patrick, de chez Adobe, répond à la question basique: what is Flex?.
Extrait:

• Flex est un moyen de produire des fichiers SWF (Flash)
• Flex est fait pour les développeurs, pas pour les graphistes
• Flex permet de développer des applications…
• Qui vont être exécutées sur le web (player Adobe Flash)…
• Ou sur le bureau (Adobe AIR)
• Ou sur des mobiles (ce n’est pas encore le cas, et c’est un des gros défauts de Flex !)

SOA

JEE 6 : Extensibility, Profiles and Pruning

InfoQ nous présente les grandes lignes de Java EE 6 dont la version finale est attendue pour Q4 2008. Ce sera la première version modulaire de Java EE grâce à l’introduction des profiles. Le débat discutable « Tomcat est il un serveur Java EE ? » deviendra officiellement caduque, Tomcat implémentera le « Java EE Web Profile ».

Les nouveautés majeures
Fini les serveurs Java EE monolythiques ! Java EE 6 devient modulaires avec l’introduction de profiles.
Ce mécanisme de profile est déjà utilisé dans Java Mobile [1] avec quelques difficultés d’interopérabilité et les promoteurs d’OSGI défendent leur modèle d’assemblage ; on se souviendra quand même du satisfecit que Rod Jonhson, le fondateur de Spring Framework, a adressé aux profiles JavaEE 6 en juillet 2007 (Spring source 2007/07 : Java EE 6 gets it right). On remarquera aussi que le débat sur OSGI est aussi présent sur la spécification JBI 2.0.

Pruning
Le processus de ‘pruning’ (ie. fin de vie) existe depuis longtemps pour les standards Java mais a rarement été utilisé. En rupture avec les versions précédentes, Java EE 6 ouvre le chantier de nettoyage des API désuètes (Java SE 7 suit la même approche). Les premiers candidats à la retraite sont :

• EJB-CMP : désolé pour les entreprises qui ont investi sur les EJB 1.x et 2.x. La suppression commence par le mécanisme de persistance EJB-CMP et il faudra s’attendra à voir rapidement suivre le reste de ces APIs.
• JAX-RPC et JAX-Registry [2] : les APIs Web Services pour Java ne vivent pas plus longtemps que les standards WS-*. Ces disparitions auront probablement peu d’impacts, XFire et Axis 1 ont souvent été préférés à JAX-RPC. Quant à JAX-Registry, son utilisation est restée confidentielle.

Les absents

On notera deux absents notables à JavaEE 6:

• Les portails java et leur gestion de contenu [3] : la vague de marketing intense des éditeurs de portails java est passée ; les promesses de réutilisabilité et de ROI on rarement été au rendez-vous. Les APIs portlet vont-elles se faire ‘pruner’ avant même de rejoindre Java EE ? Nous pressentons plutôt la création d’un profile « java portals » dont la communauté sera très restreinte. Seule une rupture majeure dans la gestion de contenu en Java permettrait de menacer la prédominance de PHP sur ce sujet.
• Les standards d’intégration JBI et SCA/SDO [4] : ces sujets semblent trop polémiques et trop politiques pour permettre d’entériner des standards Java. JBI 1.0 a déçu ceux qui s’y sont aventurés (ServiceMix, Mule, etc) et l’ébauche de la version 2.0 rencontre toujours l’hostilité d’IBM et de BEA. Ces deux éditeurs lui préfèrent les standards SCA et SDO qui rencontrent un accueil pour le moins circonspect de la part de Sun, peut-être parce que la gouvernance des ces standards est partagée.

[1] JSR 37 Mobile Information Device Profile, JSR 137 Java Game Profile, etc
[2] JSR-101 Java APIs for XML based RPC et JSR 93 Java API for XML Registries
[3] JSR-168 Portlet specification, JSR-286 Portlet Specification 2.0, JSR-301 Portlet Bridge Specification for JavaServer Faces et JSR-170 Content Repository for Java technology API
[4] JSR-208 Java Business Integration et JSR-235 Service Data Objects

Le coin de la technique

Une expérience positive sur Wicket

Après une année passée à développer une application avec Wicket, Julian Sinai, nous donne son retour d’expérience très positif. Venant du monde du « client lourd » (Swing), il a dans un premier temps évalué différents frameworks web:

• GWT: trop éloigné des autres frameworks web, pas de HTML, pas de WAR
• Tapestry: gros coût d’entrée, difficile de développer de nouveaux composants
• JSF: trop complexe

Parmi les points positifs qu’il retire de l’expérience, il insiste en particulier sur la claire séparation entre le code de présentation et le code métier, et sur la facilité avec laquelle on peut développer des composants réutilisables. Matt Raible a commenté rapidement l’article sur son blog. ]]> http://blog.xebia.fr/2008/01/21/revue-de-presse-xebia-40/feed/ 9 http://blog.xebia.fr/2008/01/07/revue-de-presse-xebia-38/ http://blog.xebia.fr/2008/01/07/revue-de-presse-xebia-38/#comments Mon, 07 Jan 2008 17:38:36 +0000 Xebia France http://blog.xebia.fr/2008/01/07/revue-de-presse-xebia-38/
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Le coin de la technique

• JSF Testing Tools
• Wicket 1.3 released
• WebSphere MQ en environnent J2EE/JEE : JMS vs. ‘MQ Java Interfaces’
• IBM ObjectGrid 6.1 fix 3 : une grille résolument ‘developer friendly’

Le coin de la technique

JSF Testing Tools

Cet article présente trois principaux frameworks permettant d’effectuer des tests unitaires JSF. Pour rappel, la principale difficulté est de pouvoir effectuer des tests en dehors du container, et grâce à ces outils il est possible de tester les composants côtés client mais aussi côté serveur.

• JSFUnit est basé sur HttpUnit et Apache Cactus. Son API permet notamment de tester le transfert de données dans un formulaire et de savoir si le managed bean correspondant à bien été mis à jour… Cet outil inclue aussi un JSF Static Analysis permettant notamment d’analyser les fichiers de configuration.
• Shale Test est un projet Apache fournissant des implémentations d’objet Mock pour les Servlets et les composants JSF.
• JSF Extensions est basé sur JUnit, HTMLUnit, et Cactus. Cet outil est composé d’un module Test-Time fournissant des objets Mock pour les composants JSF 1.2, ainsi qu’un module Design-Time pour effectuer des déploiements plus rapide (hot deploy). Cette fonctionnalité a pour but de mettre en place des tests de manière itératif durant le développement d’application JSF.

Enfin l’article termine par deux outils d’aide au développement et au monitoring d’applications JSF :

• JXInsight, se basant sur l’interface PhaseListener, permet de collecter différentes informations sur l’exécution du code (les stacks…)
• JSF Tools, sous projet de Eclipse WTP, fournit un support pour le développement et le déploiement d’application JSF.

Pour terminer, cet article présente assez bien les différents outils, mais il aurait peut être été bien de proposer des critiques sur ceux-ci, qui feront peut être l’objet d’un nouvel article.

Wicket 1.3 released

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.

Nous vous invitons à consulter la liste complète des nouveautés à partir du site d’Apache.

• Apache Wicket
• Discovering Apache Wicket 1.3 by Pachod Joseph
• Guide de migration à Wicket 1.3

WebSphere MQ en environnent J2EE/JEE : JMS vs. ‘MQ Java Interfaces’

David Currie nous rappelle dans WebSphere MQ Java in J2EE que JMS est l’API privilégiée pour accéder à Websphere MQ dans un environnement J2EE/JEE et que les historiques API « MQ Java Interfaces » devraient progressivement être remplacées [1].

Au delà d’un simple choix technique d’API (la fiabilité de JMS est aujourd’hui avérée), il s’agit d’un réel changement de culture depuis l’historique approche en langage C (user exits MQ, style de programmation des « MQ Java Interfaces », etc) vers le monde orienté objet Java / .Net [2]. Cette évolution demande un travail d’explication et de formation des équipes qu’il ne faut pas négliger.

La roadmap MQ JMS pourra aller jusqu’au remplacement de Queue Managers MQ par le Websphere Embedded Messaging Engine pour les utilisateurs du serveur J2EE d’IBM …

[1] IBM Technote : Using WebSphere MQ Java Interfaces in J2EE/JEE Environments : « This technote explains why ‘WebSphere MQ classes for Java Message Service’ is the API best suited for use in J2EE/JEE environments … »
[2] IBM DeveloperWorks : Introducing XMS : The IBM Messages API

IBM ObjectGrid 6.1 fix 3 : une grille résolument ‘developer friendly’

Le fix 3 d’IBM ObjectGrid apporte de nouvelles fonctionnalités résolument à l’écoute des développeurs avec notamment :

• Support de Spring Framework
  - Intégration aux transactions Spring et à leurs annotation @Transactional
  - Gestion par le container Spring des beans d’extension d’ObjectGrid (ObjectTransformer, Loader, TransactionCallback, etc)
• Entity Listeners similaires aux listeners JPA/Hibernate autour des événements persist, load, update et remove

On remarquera à l’occasion la poursuite de la nuit de noces entre IBM et Spring Framework dont les précédents épisodes marquant furent le support officiel de Websphere par Spring Framework (11/2007) et la présentation de Billy Newport sur l’eXtreme Transaction Processing à The Spring Experience (12/2007).

Actualité éditeurs / SSII

• Weblogic Server 10.3

Le coin de la technique

• Release de Seam 2.0
• Un vent de Websphere 7 chez IBM
• Apache Wicket 1.3.0-rc1 is released!

Actualité éditeurs / SSII

Weblogic Server 10.3

Cette nouvelle mouture du serveur d’application de BEA reste conforme aux spécifications J2EE 5 tout en ajoutant le support de Java SE 6. Donc peu de nouveautés technico-fonctionnelles, l’accent a été mis sur les performances. Cette version vient de sortir en mode ‘Tech Preview‘. La version 10.3 deviendrat-elle une version aussi performante et stable qu’est (ou fût) la version 8.1SP5+ ?

Le coin de la technique

Release de Seam 2.0

Pour rappel, Seam permet de mettre en des applications par le biais des technologies JSF, EJB 3, AJAX, BPM… Sa nouvelle version arrive avec ses lots de corrections et d’améliorations parmi lesquelles :

• possibilité d’écrire des composants Seam en Groovy
• intégration de GWT pour le rendering de page ou bien encore inclure des composants GWT dans une page JSF
• les composants Seam peuvent faire l’office de Web Service
• intégration de Hibernate Search
• syntaxe des EL améliorée

Un vent de Websphere 7 chez IBM

IBM nous prépare à Websphere 7, ses EJB3, sa persistance JPA et ses web services JAX-WS 2.0 en publiant le redbook Designing and Coding Applications for Performance and Scalability in WebSphere Application Server et en annonçant Rational Application Developer 7.5 Open Beta.

RAD 7.5, dont la beta sera disponible mi-décembre, apporte le support de support de Java EE 5 (EJB 3, JPA, JAX-WS, etc). La sortie de cette version, en avance sur Websphere 7, rassurera les clients RAD qui avaient été déçus par le décalage de plusieurs mois entre la sortie de WAS 6.1 et celle de RAD 7 (la v7 de RAD apportait le support de Java 5 et le WAS 6.1 runtime environment).

Designing and Coding Applications for Performance and Scalability in WebSphere Application Server est un RedBook de transition de l’ère des EJB 2.1 vers les nouveaux EJB 3.0 qui seront supportés par le futur Websphere 7 :

On y retrouve hélas quelques exemples légèrement défraîchis qui font penser à des copier/coller des redbooks précédents :

• Le chapitre sur l’utilisation des mécanismes de synchronisation (p99) mériteraient d’être réécrit en s’inspirant du très intéressant Google Tech Talk Advanced Topics in Programming Languages: The Java Memory Model de Jeremy Manson qui nous expliquent comment les blocs synchronized devraient être remplacé par les verrous introduis avec la librairie java.util.concurrent.locks
• Les exemples qui utilisent Vector et Hashtable pourraient avantageusement être mis à jour pour parler de List/ArrayList et de Map/HashMap
• Le paragraphe sur Struts et ses ActionForm pourrait être remplacé par son équivalent avec Struts2 ou être supprimé si IBM ne souhaite pas mettre en avant Struts2.

A côté de ces anachronismes mineurs, IBM nous livre les grands axes de la stratégie Websphere :

• SCA/SDO sont toujours des technologies clefs. Ce redbook nous explique avec clarté et raison leur rôle et leur position par rapport à EJB3/JPA : If you are developing a traditional (non SOA) application and only have relational data and are only developing in Java, then EJB 3.0 is a good choice. (p 449).
• Java Connector Architecture (JCA) est désormais la technologie standard et unifiée pour accéder aux Enterprise Information Systems (EIS) comme CICS et IMS dont les connecteurs Java propriétaires ont été remplacés par des Resources Adapter JCA [1]. Le support de l’API JCA permet une intégration élégante à SpringFramework [2].
• EJB3, JPA et JAX-WS sont les successeurs respectifs d’EJB 2.1, d’EJB CMP et de JAX-RPC ; ils sont disponibles avec WAS 6.1 sous forme de feature pack additionnels [3] ; Websphere 7 les embarquera en standard. Ce redbook sera une bonne introduction pour ceux qui n’ont pas encore eu le temps de découvrir ces nouvelles technologies.

Pour conclure, RAD 7.5 et ce redbook sont principalement des previews des technologies JavaEE 5 (EJB3, JPA, JAX-WS, etc) que nous attendons avec impatience et qui seront disponible avec Websphere 7.

D’ici à y voir les prémices d’une grande opération de teasing pour préparer l’imminente arrivée de Websphere 7 …

[1] Voir IMS TM Resource Adapter et CICS Transaction Gateway.
[2] Voir Access CICS applications with Spring par Thierry Templier pour JavaWorld.
[3] Voir WebSphere® Application Server Version 6.1 Feature Pack for EJB 3.0 et Feature Pack for Web Services for WebSphere Application Server V6.1

Apache Wicket 1.3.0-rc1 is released!

Le projet Wicket avance et entre en release candidates. Cela signifie que seulement des corrections de bugs seront faites jusque la sortie finale de la version 1.3.
Au programme de cette release :

• un guide de migration à partir de la version 1.2 : l’API a évolué/changé et donc pas mal de changements sont à prévoir.
• beaucoup de bugs ont été corrigés, et les évolutions sont nombreuses. Voici la liste.

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 …