Le blog de L'ami S'ami

Il m’arrive régulièrement dans ce blog d’évoquer le sujet GWT. Ces derniers temps, je n’ai cessé de découvrir et redécouvrir ce Framework qui a tout d’un futur grand et que j'ai testé pour la première fois sur un projet d'envergure il y a de cela 6 mois. Depuis cette date, GWT ne m'a quasiment plus quitté.

Lorsque je souhaite maîtriser un nouveau sujet technique, qu’il soit lié au Web, à l’accès aux données ou à l’orientée services, j’avoue que je rentre en hibernation quelques jours et j’essaye d’écrire une formation couvrant de manière quasi exhaustive le périmètre fonctionnel du sujet en question. Parfois on pense maîtriser un sujet, mais on ne le maîtrise vraiment que lorsqu’on se plonge dans ses arcanes, ses limites, tout en essayant de le transmettre de manière pédagogique.

Un bon prof me disait souvent à la Fac, « si tu veux être certain d’avoir compris un sujet, expliques-le à ton voisin, s’il comprend, c’est que tu as compris ». La formation c’est un peu comme écrire un livre, sauf que la phase de production est plus courte (plus intense aussi sûrement) et le résultant plus synthétique. Mais dans le fond, les objectifs sont les mêmes, couvrir le sujet en profondeur et dans sa totalité. Et puis il faut avouer qu'il n'existe aujourd'hui aucune formation francophone sur GWT 1.4.

Pour en revenir aux aspects techniques, plus j’explore le cœur du Framework GWT et plus je me dis qu’un vent de génie a soufflé dans la tête de son créateur : Bruce Johnson. GWT n’est pas un Framework ordinaire. GWT a rempli une case au milieu de centaines d’autres Framework AJAX et s’est taillé en moins de 6 mois une réputation qui ne va cesser de croître dans les mois à venir. Et pourtant, contrairement à d’autres outils AJAX, GWT n’a rien d’attirant au premier abord. Avec un projet hébergé sobrement par Google, une documentation plutôt sommaire et des exemples peu ou pas sexy, rien ne pousse à acheter lorsqu’on entre la première fois dans la maison GWT. Une situation qui s'explique lorsqu'on sait l'enseigne, désormais incontournable, qui se cache derrière GWT : Google. Privilégier le contenu à la forme, l’efficacité à la complexité et la performance aux strasses et paillettes, soit-ils Web 2.0. Tels sont les mantras de l'éditeur californien.

Mais la richesse de GWT est ailleurs. La richesse de GWT est dans son modèle de développement et sa productivité hors pair.

Certains signes ne trompent pas. Il m’arrive tout au long de l'année d’avoir à faire des démonstrations à certains clients des dizaines de Framework AJAX du marché. De JSF à ASP.NET en passant par Struts 2, Bindows, Backbase ou Echo2. J’essaye de tout montrer tout en restant le plus objectif possible. Et systématiquement lorsque vient le tour de GWT, les voix se taisent et les mâchoires restent entrouvertes devant la simplicité du modèle de développement et la magnifique démo de contact Office, sûrement l’application la plus aboutie disponible aujourd’hui dans cette technologie.

Avec GWT, un cap a été franchi. Alors que tout le monde annonçait (et moi le premier) il y a 3 ans l’explosion des Framework évènementiels que sont ASP.NET et JSF, force est de constater que l’arrivée d’AJAX n'a été programmée par personne. Du coup, tous les Framework ayant été pensés avec une philosophie centrée sur le server (server-centric) ont dû bon an mal an intégrer le mode Asynchrone et la gestion dynamique de l’arbre DOM comme une sorte de rustine que l’on rajoute sur des fondations inadaptées. Personnellement, je pense qu’intégrer AJAX dans un cycle de vie de pages tel que le proposent ASP.NET ou JSF est une erreur. Attention, je ne veux pas dire que cela n’a aucun sens. Fonctionnellement et d’un point de vue esthétique sûrement, mais techniquement il y a une incohérence de fond. Le cycle de vie d’une page ASP.NET est du type Form-Page-PostBack. Celui d’AJAX se rapproche plutôt du Bloc-Page-Postback. Du coup, mélanger ces deux modèles revient à valider côté serveur une réponse provenant soit d’un bloc HTML soit d’un formulaire HTML. Or un bloc n’est pas une page et ne doit pas être traité comme tel, les mêmes évènements étant gérés sur le poste client. C’est pourquoi, bien souvent, ces Framework fournissent côté serveur un paradigme AJAX ne faisant pas intervenir toute la pile d’évènements standard (LectureQueryString, Load, Event Call, Rendering, …). Sans compter qu'une taglib est tout sauf adapté aux mécanismes AJAX, plutôt clients.

Et pourquoi y aurait-il dans une page Web des contrôles de type AJAX et des contrôles de type FPP ? Comment peut-on imaginer à terme maintenir correctement ce type de code ?

GWT a mis un coup de pied dans cette fourmilière en déportant tout ce qui avait un lien avec l'IHM côté client. Avec cette stratégie, GWT a déjà détrôné dans les esprits (uniquement auprès des techniciens férus pour l’instant) l’ensemble des Framework Web JEE ou .NET en place et les conduira inexorablement à la retraite anticipée. Lorsque je développe avec GWT, je produis en moyenne 5 fois plus vite qu’avec des technologies alternatives tout en disposant de 5 fois plus de possibilités fonctionnelles grâce à l’utilisation systématique d’AJAX côté client. Non seulement, la productivité est au rendez-vous mais ce modèle basée sur la compilation statique de code Java en JavaScript ouvrent de nouvelles portes (et en ferme aussi quelques unes il faut l'avouer). Ajouté à cela, l'offre en termes de Designers WYSIWYG et vous comprendrez que le cocktail ne peut être que gagnant.

Je me revendique plutôt comme un mauvais développeur JavaScript consentant, mais jamais je n’ai mis autant d'enthousiasme à créer des composants spécifiques (custom widgets) en m’appuyant sur les fantastiques bibliothèques de scripts JavaScript hébergées sur dynamicdrive.com (que je voyais plutôt comme de jolies gadgets).

Pour preuve, cet xpmenu qui est à la base un menu proche du StackPanel GWT avec un effet accordéon en plus. Actuellement un code JavaScript effroyable à intégrer et à maintenir. Il m’a fallu 30 minutes pour en faire un XPMenu GWT capable d’accepter n’importe quel widget et entièrement générique. Simplement avec ce code en dérivant de la classe Widget et en implémentant les routines (Java) du DOM ad-oc.

Pour utiliser ce composant spécifique, les développeurs n'auront simplement qu'à écrire du code Java à la Swing avec la liberté de remplacer les liens hypertextes habituels par n’importe quel widget. On peut imaginer insérer des arbres, d’autres menus ou même un DataGrid à l’intérieur de ce composant (ce qui n’a aucun sens bien entendu). Bref, de nouvelles perspectives que la complexité de JavaScript a toujours freiné.

XPMenu xp = new XPMenu();
xp.addMenu("Menu");
// Composition de Widget TextBox à la place des liens hypertextes
final TextBox tb = new TextBox();
final TextBox tb2 = new TextBox();
// Ajout des menus et sous-menus
xp.addSubMenu("Menu", "Sous menu tb Custom",tb);
xp.addMenu("Autre Menu");
xp.addSubMenu("Autre Menu", "Sous menu",tb2);
tb.addKeyboardListener(new KeyboardListener(){
public void onKeyDown(Widget sender, char keyCode, int modifiers) {
tb2.setText("You typed on a key lammer !");
}
});
xp.addSubMenu("Autre Menu", "Autre Sous menu",new Label("rien"));
xp.addClickListener(new ClickListener(){
public void onClick(Widget sender) {
tb2.setText(tb2.getText()+" click");
}});
RootPanel.get().add(xp);


Mais GWT c’est aussi :
- l’internationalisation, un bijou d’originalité avec les constantes et les messages typés
- l’intégration avec un existant HTML
- les optimisations permanentes recherchées par le compilateur JavaScript
- le modèle évènementiel (bubbling, sink/unsink, …)
- le modèle composite
- la productivité du cycle dev/test/debug

Etc, Etc…

Ce qui ne veut pas dire que j’ai un regard béat sur tout ce que propose GWT, je trouve par exemple que l’implémentation de la partie serveur laisse à désirer en termes de design. Proposer aux services RPC d’hériter d’une servlet technique RemoteServiceServlet chargée des opérations d’invocation et de sérialisation/désérialisation est une erreur à mon (humble) avis. On se retrouve aujourd’hui à devoir configurer un handler Spring développé par un projet annexe pour invoquer nativement ses propres services POJO. Pas vraiment utile pour ceux ayant un existant EJB 3, Web Services, RMI ou Corba et ne souhaitant pas alourdir leur existant avec Spring. En deux mots, il aurait été plus judicieux de fournir un modèle par délégation sur lequel serait venu se greffer un Proxy (un DynamicProxy ferait très bien l’affaire). On aurait eu du coup simplement à générer un proxy EJB 3 ou Soap passé ensuite par délégation à RemoteServiceServlet. Dans les mois à venir, je ferais sûrement à l’équipe GWT des propositions dans ce sens, une telle implémentation n’est pas très compliquée, les outils sont là.

Bref, c’est pour toutes ces raisons que j’aime GWT et mettrait tout en œuvre pour faciliter son adoption au sein de la communauté Java (je rêve d'un équivalent .NET) mais aussi dans mon travail de tous les jours. L’écosystème GWT est en marche, tel un Hibernate à son époque (dans le fond, GWT est aussi une sorte de mappeur Java/JavaScript comme l'est un mapper Objet/Relationnel). Et si j’entends bien ici ou là de nombreux clients regretter le fait que Google ait la main mise sur ce projet, je continuerais à les rassurer en avançant le fait qu’Eclipse est géré par IBM et Java par Sun depuis des années. Le tampon "Open Source" est important malgré tout car il permettra un Fork le jour où Google cherchera à travestir son bébé. Je n'y crois pas un instant. En revanche, il n'est pas impossible que GWT soit copié dans les années à venir sous une bannière plus "standard" (Hibernate l'a bien été).

Pour en revenir à l’écosystème, les livres sérieux sont déjà là, 600 pages dans GWT in Action (en vente demain dans les bacs Français). Les sites, déjà nombreux, commencent à fleurir de toutes parts. Les blogs (merci à Didier pour ce fantastique travail de synthèse), les articles, les cas d’exemple, les innombrables éditeurs de widget (il y a un marché à prendre). Et surtout la formation GWT (voici le sommaire détaillé de celle que je viens d’écrire, à noter que je ne sais pas encore quand et comment elle sera commercialisée vu l'engouement autour de ce cours, nous avons décidé de le commercialiser, envoyez-moi un mail si vous êtes intéressés).

Si GWT peut paraître au premier abord très simple, sans de bonnes pratiques, on peut vite s’y perdre et se retrouver dans une impasse. Il existe des patterns de navigation qu’il convient de respecter absolument car tout se passe « under the hood » comme disent les anglo-saxons. On ne le répètera jamais assez, une bonne formation est la clé du succès :-)

Pour l'avoir testé en avance de phase avec des cas tordus, la version qui sortira d'ici quelques jours (1.4) est une version stable qu'on peut sans risque mettre en production (si vous n'êtes pas un féru de Safari sous MacOS). Alors lancez-vous !