GWT, framework Web Java developpé par Google permettant notamment de développer des interfaces riches, était à l’honneur pour sa version 2.0 lors de l’OpenRex. Ce billet constitue mon retour sur cette présentation.
Un OpenQuoi ?
Ippon Technologies organise depuis le début de l’année des retours d’expérience ouverts au public et animés par ses employés, sous le doux nom d’OpenRex. Bien que de taille modeste (35 places), ces présentations permettent d’avoir un retour direct sur l’emploi de technologies appliquées au monde de l’entreprise.
Et GWT 2.0 ?
L’intervenant du jour travaille sur GWT depuis plus d’un an, sur un projet d’interface de gestion de billets dans lequel des problématiques de performance sont en jeu.
Parmi les principaux apports de GWT 2.0, on trouve notamment :
- LayoutPanel, UiBinder et CSSRessource
- * la mise en page par CSS au lieu de tableau
- * le redimensionnement CSS au lieu de JS
- * la séparation de la présentation / gestion des évènements
- * ma possibilité d’insérer du HTML/CSS (évite la surcharge de widget)
- Pattern MVP : Modèle-Vue-Présentation
- * Facilite les tests unitaires
- * La vue est moins couplée au modèle, le couche présentation s’occupe de lier le modèle à la vue
GWT et les performances
Dans le cadre de GWT, le terme «Performances» signifie les performances côté client.
- A éviter : trop de requêtes HTTP
- * récupérer des données inutiles (éviter de faire des services génériques)
- * Utilisation trop intensive de widgets
- A envisager : regrouper les requêtes en batch
- Charger les widgets au plus tard
Parmi les outils utilisés, l’intervenant a notamment cité :
- Inspector Widget : inspecte le DOM, permet de lister les widgets (compter le nombre de widget) avec les évènements associés
- SpeedTracer : outil complet permettant de tracer en détails le temps de rendu de chaque widget de la page. Il a été developpé avec GWT en tant que plugin Chrome ; en récupérant les sources, cela peut donner une idée de la puissance de GWT.
Tester avec GWT
Un des autres aspects de GWT concerne la testabilité. Un des points clés consiste à parvenir à bien isoler le code afin d’éviter les dépendances sur les composants internes qui utilisent du JS. Les GWTTestCase (une surcouche de JUnit) permettent de couvrir tous les tests.
Et après ?
Le framework évolue au fur et à mesure des versions, et les design pattern avec, ainsi :
– le patternMVCétait préconisé pour le version 1.5,
– le pattern MVP avec la version 2.0,
– l’association RequestFactory – Activity – EditorSupport pour la prochaine version 2.1.
– 2.2 : Prise en compte de l’HTML5
Mon sentiment
GWT évolue beaucoup, au fur et à mesure de ses versions. Cela peut en « déboussoler » certains, mais cela va dans le bon sens : Google ne dort pas sur ses lauriers et fait en sorte que son framework s’améliore toujours (on constate par exemple l’impact du projet Google Wave sur GWT).
Néanmoins, GWT reste un framework complexe à maitriser (notamment du point de vue des performances) et demande un minimum d’expérience pour être utilisé à bon escient.
