On ne présente plus GWT, ou Google Web Toolkit, le framework de développement de site Web par Google. Son principe est intéressant : on code tout en Java, on précise au framework quels sont les packages Java qui sont destinés à une utilisation côté client (nous sommes dans un contexte Web, vous l’aurez compris), et à la compilation GWT compile le code serveur en servlets Java classiques et le code client est transformé en Javascript.
GWT utilise massivement l’AJAX : du point de vue du navigateur, toute l’application tient dans une seule page dont le contenu change avec les actions de l’utilisateur (boutons, etc.). Le pattern utilisé est Modèle - Vue - Presenteur, qui peut être renforcé par l’addition du framework MVP4G. Ainsi, les couches vue et présenteur sont destinées à être utilisées sur le client (la vue n’étant censée faire que de l’affichage, et la gestion des actions, l’appel aux services en RPC via Gin et Guice étant destinés au présenteur). Les couches service et DAO sont bien évidemment destinées au serveur. On utilisera allégrément l’injection de service et les contextes pour utiliser les classes DAO et Serveur (merci les beans !)
=======================
Maintenant que j’ai présenté rapidement (très rapidement, on en conviendra) le framework, voici quelques avantages, inconvénients, limites, points forts que j’ai pu expérimenter.
Le contexte dans lequel j’utilisais ce framework est le suivant : il s’agit de développer une application pour smartphones (particulièrement des BlackBerry, je reviendrais probablement sur le sujet dans un article futur), qui doit permettre à des chauffeurs routiers d’obtenir des informations sur les missions de transport qui leur ont été affectées, et de transmettre au siège l’avancement de la mission en cours et leur position GPS. Il faut donc prendre en compte dans l’architecture la lenteur du réseau (au mieux, de la 3G), son instabilité, les limitations induites par le smartphone, la petite taille de l’écran, l’écran tactile, et l’utilisation de l’application par des personnes dans un cadre professionnel. Elle doit donc être un outil intuitif, avec des fonctionnalités faciles d’accès pour être un support à leur travail et non pas une gêne, et ainsi garantir son adoption.
Le premier inconvénient du framework vient de sa force : la traduction en Javascript. En effet, toutes les fonctionnalités du Java ne sont pas prises en charge par GWT, ou ont été adaptée dans le framework pour supporter la traduction. Et une fois l’ensemble traduit en Javascript, on peut avoir des surprises, par exemple dans la gestion des timestamps. Les navigateurs ont parfois des façons bien à eux de gérer les dates, et le traitement en Javascript est impacté. Ainsi, la gestion des fuseaux horaires est parfois exotique (fuseaux décalés, traduction en heure GMT ou UTC, etc.). Cela conduit à devoir mettre en place des systèmes pas toujours très élégants pour contourner les problèmes.
GWT est un framework en évolution rapide, et malheureusement la rétro-compatibilité n’est pas forcément respectée entre les versions. De même, les différents frameworks que l’ont ajoute n’arrivent pas toujours à suivre, et faire une montée de version de GWT implique beaucoup plus qu’un changement de .jar et de classpath. De plus, il faut faire monter de version le plugin GWT pour Eclipse qui permet de compiler et piloter depuis l’interface graphique sans s’amuser à écrire un fichier Ant. Ainsi, s’il est possible de retrouver d’anciennes versions de GWT bien pratiques pour recompiler d’anciens projets, il est parfois délicat de trouver les pugins correspondants et cela peut être problématique.
Les composants graphiques GWT sont limités, au style particulier et manquent de finesse. Par exemple, il est délicat par exemple de placer une liste déroulante mappée sur des valeurs extraites d’une base de données dans une cellule de tableau. On en arrive rapidement à devoir surcharger des composants, et à définir à la main le HTML généré pour obtenir un comportement adéquat. Cela se fait plutôt bien, l’architecture des composants semble prévue pour et définir de nouveaux composants se fait assez rapidement. Il est possible qu’il existe des bibliothèques de composants à ajouter au framework, néanmoins cela sortant du cadre de ce projet cela n’a pas été considéré.
Les applications GWT sont intégralement chargées côté client lors du premier accès à une page, et les vues sont générées à ce moment là. Le chargement doit donc être réfléchi, pour ne pas être trop long, et pour pouvoir être supporté par le réseau mobile. De plus, les vues sont générées lors de ce chargement, ce qui implique par exemple que les valeurs des listes déroulantes placées dans les tableaux sont figées. Il n’est pas possible d’ajouter des composants dans une vue, il faut jouer avec les méthodes setVisible() des composants pour changer l’affichage d’une même vue au cours de l’exécution.
Enfin, un soucis majeur est que du point de vue du navigateur, l’application possède une seule et unique page. Il n’est donc pas possible de faire un rechargement (on se retrouve automatiquement sur la page d’accueil de l’application), et surtout l’utilisation des boutons “Précédent” et “Suivant” ne renvoient pas sur la page précédente vue dans l’application, mais sort de l’application. Il est possible de simuler la navigation dans l’application en ajoutant des tags dans la barre d’adresse (objet History), mais le système n’est pas aussi complet qu’une complète navigation par page et l’utilisation de l’historique est généralement assez instable.
===========================
Comme on l’a vu, ce framework est donc très intéressant, permet de développer relativement rapidement mais pose des problèmes. Il est de plus peu adapté à une utilisation mobile, du fait des navigateurs adaptés présents sur les téléphones qui ne sont pas toujours pleinement supportés ou détectés, le User-Agent étant par exemple le même sur un BlackBerry ou un Androïd mais le comportement en matière de Javascript est souvent bien différent (à la faveur d’Androïd d’ailleurs). A utiliser avec parcimonie donc, et en prenant soin de contrôler son adéquation avec l’utilisation qui sera faite de l’application.