Pour cette présentation, pas d’explication sur comment Wicket fonctionne, uniquement une séance de codage en binôme, dont le but était de montrer avec quelle rapidité (1 heure) on pouvait développer une application avec des fonctionnalités dynamiques assez puissantes. Dommage, on aurait peut-être voulu en savoir un peu plus sur la façon dont Wicket génère son rendu Html.

 

Fonctionnalités

Contrairement à de nombreux autres frameworks web, on ne jette pas la maquette statique et encore moins son ancien site à la poubelle pour tout refaire de zéro : on part des fichiers Html et on intègre des attributs et des balises Wicket aux endroits précis où l’on souhaite introduire un comportement dynamique. Ainsi, la collaboration entre le web designer et le développeur Java s’en trouve grandement facilitée.

On peut également rajouter des comportements (behavior) pour chaque composant, que ce soit pour la validation du contenu d’un champ ou pour ajouter un comportement dynamique (Ajax) à un composant.

Malgré son jeune âge, Wicket semble, grâce à ses Model, bien plus abouti que ses concurrents concernant le Databinding et la validation des données entrées. Zenika en a profité pour présenter une de leurs réalisations : un plug-in qui génère la validation des données côté client en se basant sur YUI. Wicket fournit également une console de debug AJAX pour aider le développeur au cours de ses développements.

Enfin, on peut très facilement (par un simple héritage entre classes Java) créer des composants réutilisables, comme des Panels, qu’on référence dans plusieurs pages.

Les URLs générées lors de cette session n’étaient pas très belles (affichage des packages Java), mais on peut y remédier en faisant correspondre des URLs simples à nos pages wicket.

Exemple :
mountBookmarkablePage("/Acceuil", Acceuil.class)
mountBookmarkablePage("/listeUtilisateur", UsersList.class)

Le templating (comme le fait Tiles ou Sitemesh) est intégré dans le framework. Il est extrêmement simple à mettre en œuvre : pour se baser sur un template, une page (représentée par une classe), n’a qu’à hériter du template sur laquelle elle veut se baser. Difficile de faire plus simple.

Côté packaging, les adeptes de Maven vont s’indigner : par défaut, fichiers Html et classes Java sont mélangés dans les mêmes dossiers. Pas de panique, on peut spécifier à Wicket l’emplacement des pages Html, et ainsi gérer l’arborescence de ses ressources statiques d’une part, et dynamique d’autre part.

 

Wicket et les autres

Carl a commencé sa présentation en faisant un parallèle entre la rivalité Hibernate/JDO et Wicket/JSF. Il pense que Wicket est l’outsider de JSF et va s’imposer comme Hibernate avec JDO. Certains pourraient penser que la concurrence est faussée, JSF étant sur le déclin, mais JSF 2.0 pourrait relancer la donne. GWT, tout comme Wicket, se base sur du code Java pour générer son rendu Html+Javacript. Le code généré par Wicket est indexable par les moteurs de recherche, ce qui n’est pas le cas de GWT. Les deux possèdent de solides composants prêts à l’emploi. Côté performances il serait intéressant d’avoir un comparatif sur le sujet…

Tous les 3 (Wicket, JSF et GWT) sont des frameworks Java orientés composant et se basent sur un modèle événementiel. Mais on retrouve également les concepts de convention over configuration (http://en.wikipedia.org/wiki/Convention_over_configuration) comme on le retrouve dans Groovy, Rails et Stripes : chaque page est constituée d’un fichier Html et d’une classe Java du même nom.

 

Concours Wicket

Pour finir Carl et Nicolas ont lancé suite à leur séance de coding le concours du « meilleur framework RAD », les critères étant :

  • le temps de réalisation,
  • le nombre de lignes de code produites,
  • le nombre de lignes de configuration

http://blog.zenika.com/index.php?post/2009/03/10/Concours-D%C3%A9velopper-une-application-web-en-Wicket3

Bilan de la soirée :

  • 12 classes (classes internes incluses et la classe Contact exclue)
  • 163 lignes de codes
  • 1 seule configuration XML (Le filtre dans le web.xml)
  • 0 lignes de javascript codées
  • Temps de développement < 1 heure

 

Article rédigé par les sfeiriens du Paris JUG : Mohamed Abdennebi, Fabien Baligand, Tanguy Bayard, Tarik Filali Ansary, David Martin... au total plus de 10 sfeiriens à cette session !