Blog de ZedroS

Un article de joseph_p    7 Commentaires

Pourquoi Wicket ?

Je vais tenter d’éclaircir sur les raisons de mon choix de Wicket.

Tout a commencé avec mon envie de trouver un framework web Java convenant à mes besoins. A l’époque ces besoins étaient un peu flous, mais les idées directrices étaient les suivantes :
– Simplicité : aucune envie de me plonger dans des architectures excessivement complexes, surtout vue l’idée de site web, assez basique, que j’avais en tête,
– Efficacité : les choses simples devraient l’être, et les choses complexes et spécifiques point trop compliquées non plus,
– Open source : je fais tout ça sur mon temps libre, aucune envie donc de payer ou d’en faire bénéficier un vendeur de code fermé.

J’avais d’autres idées en tête, mais rien de clairement défini. Au fur et à mesure de mes explications celles-ci devraient toutefois apparaître.

Ainsi, répondant à mon envie, je commençais à regarder. Ayant acheté un livre sur JSF, je commençais à expérimenter la chose. Rapidement, cependant, la complexité de JSF, entre fichiers XML, cycle de vie et ainsi de suite, s’avéra rapidement trop consommateur de mon temps libre, particulièrement pour réaliser des éléments non déjà existant. L’environnement de dév, en plus, ne semblait pas folichon. Il est à noter que, à l’époque, je ne connaissais pas le Visual Pack de Netbeans, qui a pourtant l’air bien utile de ce côté-là.

Ainsi, j’abandonnais JSF.

Struts n’était pas trop une option envisageable : tout le monde le disait déjà presque mort et dépassé par de nombreux nouveaux frameworks. Les JSP n’étaient pas pour me plaire non plus, du fait notamment de toutes ces pages pleines de balises et assez souvent de code métier.

Aussi, je suis parti sur Tapestry, en achetant le livre Enjoying Web Development with Tapestry, de Ka Iok ‘Kent’ Tong. Cet excellent livre me donna rapidement un bon aperçu de ce framework. Je pus rapidement jouer avec.

Cependant, rapidement, des questions apparurent.

En effet, il s’agissait de Tapestry 4, 4eme version du framework donc, mais une version déjà bien différente de la 3eme…A suivre la mailinglist, il apparut rapidement que pas mal de monde était donc resté sur Tapestry 3, provoquant d’ailleurs une certaine confusion sur la mailing list.

De plus, Tapestry 4.1 arriva, avec encore une fois pas mal de changements. Ma petite application devait être revue pour fonctionner à nouveau. En fait, les développeurs derrière Tapestry ne semblaient pas se soucier outre mesure des personnes utilisant telle ou telle version, en fournissant par exemple des guides montée de version. Aussi, Tapestry 5 était déjà en cours, un framework quasiment neuf par rapport à Tapestry 4. Quel pérennité alors pour mon code ?

Et même si Ka Iok ‘Kent’ Tong donna rapidement une version mise à jour de son pdf, j’étais à présent prudent vis-à-vis de Tapestry.

Je commençais aussi à réaliser des aspects déplaisants dans Tapestry :
– possibilité de mettre pas mal de balises spécifiques à Tapestry dans les pages, tout comme des jsp grosso modo,
– les composants ne sont pas vraiment héritables, ce qui gêne forcément la réutilisation,
– le framework n’était pas assez DRY (Don’t Repeat Yourself, « ne pas se répéter ») à mon goût, devant écrire pas mal de chose pour définir une page.

Au final, je finis par rejeter Tapestry.

Je commençais donc à nouveau à regarder tout autour de moi. Je jetais un rapide coup d’œil à Wicket, mais grails faisait grand bruit à l’époque, aussi je partis dessus. Ce fut une expérience fort intéressante, tant pour groovy que le framework web. Cependant, rapidement, je décidais de stopper pour les raisons suivantes :
– j’avais toujours du mal avec groovy, même si c’est quelque chose d’impressionnant
– grails est également fort intéressant, et s’intègre très bien avec Spring et Hibernate, frameworks dont je n’avais qu’une faible connaissance. Les aborder via une surcouche comme groovy me semblait un poil trop complexe. De même pour créer des éléments spécifiques dans grails. Si j’avais été plus à l’aise en Java (particulièrement Spring et Hibernate), cela aurait été différent, mais là ça faisait trop à la fois.
– Enfin, grails a aussi toute une syntaxe disponible dans les pages html, à la sauce ASP/JSP, ce qui ne me plait pas trop in fine.

Aussi, à nouveau, je repartais en chasse.

GWT eu une rapide attention de ma part, mais je le trouvais trop « ajax ». Je voulais un site assez léger, ce qui à mes yeux ne colle pas avec quelque chose très orienté ajax comme GWT.

Puis je suis tombé sur cet article : http://www.oreillynet.com/onjava/blog/2007/01/wicket_another_java_web_framew.html

En gros, l’auteur y présente le framework Wicket ainsi :
– beaucoup de code côté Java, peu dans la page
– peu de balises spécifiques
– de grandes possibilités, notamment pour les choses complexes, notamment en Ajax, tout en restant simple.

Au final, l’auteur concluait que Wicket n’est pas un framework que l’on apprend en un instant, mais qu’en contrepartie, il s’agit d’un framework orienté composant permettant de faire des applications propres, bien conçues et simples à modifier. En somme, le framework pour faire aisément des choses compliquées en Ajax. Pas si mal ! Aussi décidais je d’aller voir la chose de plus près.

Ayant toujours en mémoire le livre de Kent Tong, j’achetais dans la foulée Pro Wicket, de Karthik Gurumurthy. Même si je trouve ce livre moins éclairant que celui de Kent Tong, cela me permit de rapidement découvrir le framework, et tout y semblait vraiment bien.

Décidant de pousser un peu la bête, je commençais alors à faire un des ces composants spécifiques et complexes que j’avais en tête. Et ce fut la révélation : la mailing list est tout simplement exceptionnelle ! Igor Vaynberg, qui est je crois le leader du projet (à en croire Apache où Wicket est actuellement en incubation), répond à tous les mails sans réponse et complète même souvent les autres réponses. Une aide précieuse et impressionnante ! Encore mieux, les développeurs du framework ne sont pas des zélotes déchainés : ils conseillent assez souvent aux « chercheurs de frameworks » d’autres frameworks si ces derniers semblent mieux convenir aux besoins exprimés.

EDIT : Igor n’est pas le leader du projet, comme il me l’a gentiment fait remarquer (cf ses commentaires). Autant pour moi

Un point important à mes yeux, surtout que l’architecture elle-même du framework me plaisait déjà bien :
– possibilité de faire ou réutiliser des composants, en y intégrant ou non, selon les besoins, leur partie html,
– les balises wicket dans les pages html sont réduites au minimum. Aucun risque que tout le code métier se retrouve dans la page !
– simple et efficace : à chaque page html, une classe Java. Direct et rapide : avec la réutilisation ou l’héritage de composants aussi bien que de pages, les possibilités sont réellement multipliées sans effort
– plein de bonnes idées, des fichiers de propriétés héritables (plus d’infos à venir sur ce point) à l’ajax aisé. La façon d’interagir avec les données, via une notion de « Modèle », est particulièrement utile, notamment pour les listes et les choses similaires.

Ainsi, je creusais de plus en plus la bête… et je le fais encore. Cela va-t-il durer ? L’avenir le dira !

Ah, encore quelques mots : depuis que je me suis mis à Wicket, la communauté à décider d’arrêter le développement de Wicket 2.0, qui aurait introduit de nombreux changements dans l’API. Pourquoi ? Simplement parce que les gains attendus de ces changements ne furent pas considérés comme suffisant par rapport à l’effort qu’implique toutes les migrations qui auraient dues être réalisées. De plus, la plupart des apports de Wicket 2.0 pouvaient être « back portés » dans Wicket 1.3. Impressionnant non ?

Et vu que certaines de ces fonctionnalités semblaient vraiment intéressantes, j’utilise wicket 1.3 depuis la semaine dernière et… ça marche bien. Mes prochains articles concerneront donc cette version.

J’espère que cette longue lecture vous a intéressé. Quoiqu’il en soit, je me sens mieux et… je peux désormais commencer des choses plus techniques sur Wicket !

Tous les commentaires sont les bienvenus.

ZedroS