GWT a été utilisé sur le projet XYZ pendant plus de 6 mois et c'est une première pour le pôle édition de logiciel de mon client: un retour d'expérience s'impose.
GWT : La réponse à l'expression des besoins
Le besoin
- Faire une application Web ergonomique
- Être isofonctionnel avec l'application à refondre (= client riche Eclipse RCP + Serveur)
- Réutiliser les services existants
- Puis, ajouter des fonctionnalités majeures (notion magasin, refonte éditions, etc...)
Les atouts de GWT
GWT c'est la possibilité d'écrire des applications "AJAX Web 2.0 new age technologies" mais sans écrire de Javascript ! On réalise uniquement du code JAVA qui ensuite est compilé et optimisé en Javascript.
- Développement
- On écrit du code Java, puis on peut voir les changements immédiatement sans recompiler (hosted mode + refresh)
- On peut mettre des points d'arrêt sur du code AJAX dans le debugger Java
- On compile et déploie du "Compiled and deploy optimized, cross-browser JavaScript"
- Fonctionnalités
- Communication avec le server via un système RPC simple ou via JSON, XML ou requête HTTP simple (soumission de formulaire)
- Optimisation du javascript téléchargé par les utilisateurs en fonction de leur profil (langue + navigateur)
- Réutilisation des composants graphique sur différentes application en découpant par module les différentes briques
- Possibilité d'utiliser d'autres librairies Javascript ou de coder du javascript directement
- Support simple de l'historique du navigateur avec les boutons précédant, suivant
- Gestion efficace de la localisation et de l'internationalisation
- Un choix productif d'outils de developpements (Eclipse, Netbeans, Intelli )
- Teste du code avec JUnit
- Possibilité d'étendre et contribuer à Google Web Toolkit qui est open source
Le choix de la librairie graphique
GWT seul permet de mettre en œuvre des application de type client riche mais pas de manière productive.
En effet, la gallery de widgets parle d'elle même. Il manque cruellement de composants graphiques de haut niveau pour réaliser des applications d'entreprise. Ce manque est en passe d'être comblé (prévu pour fin 2009 avec GWT 2.0) mais en attendant il faut faire sans.
Il faut donc se tourner vers des librairies tierces qui sont assimilées à une "surcouche" graphique. Il en existe 3 majeures:
- GWT-EXT (celle qui a été retenue)
- EXT-GWT ou GXT (payante pour des projets non libres, gratuite pour les projets open-source)
- smartGWT (pas assez mature au moment du choix, et maintenant ?)
Après 6 mois d'utilisation, même si il existe certains points de blocage avec la librairie GWT-EXT, on peut affirmer qu'elle a rempli pleinement son rôle:
- Apporter des composants graphiques de hauts niveaux
- Tableaux avec colonnes, tri, regroupement etc.
- Arbres avec drag & drop
- Validation de formulaire
- Classes de facilitant graphiques
- Apporter un style graphique (CSS) d'entreprise pour l'application
- etc...
De plus, GWT-EXT met à disposition d'une bibliothèque d'exemple très pratique :
- Pour choisir les composants graphiques lors de la conception
- Pour trouver des exemples de codes lors du développement
Par contre, après 6 mois d'utilisation, le projet GWT-EXT a été figé par l'équipe des développements et seul des corrections seront prises en charge. Le responsable du projet a changé d'équipe ainsi que de projet pour créer smartGWT qui est à présent assez mature pour réaliser ce type d'application. Ce qui n'était pas le cas en octobre 2008, date de début du projet. La release 1.0 de smartGWT n'est pas encore d'actualité en mars 2009 puisque le produit est encore en beta. Il faudra peut être prévoir une tache de refonte de la couche graphique avec un nouveau framework (smartGWT ou GXT ?).
La montée en compétence rapide
Après seulement quelques jours de lecture et de suivi d'articles et tutoriels en tout genre sur GWT, on est à même de mettre en place une application à condition d'avoir déjà une expérience significative en développement Java EE.
Les principaux atouts qui facilitent la vie avec GWT :
- Code 100% JAVA
- Très peu de CSS
- Presque pas de javascript
- Une configuration simple
- Une ouverture de la solution à l'existant en entreprise (intégration de ACEGI, des services existants, etc...)
Comme rien n'est parfait, voici quelques points bloquants lors du développement :
- Impossibilité de debugger directement dans un navigateur (obligation d'utiliser le hosted mode)
- Cette fonctionnalité sera implémentée dans GWT 2.0
- Limitation du composant graphique des arborescences multi colonnes (GWT-EXT ColumnTree)
- Aucun cadre de développement ou presque... Vous avez la parole ! Pas si simple...
- To be continued...
La mise en place de pattern techniques
GWT n'impose rien d'autre qu'une classe servant de point de départ pour la construction de l'application. On peut choisir de composer son application dans le plus grand n'importe quoi ou d'agencer le code pour faciliter la maintenabilité et la pérennité... au choix !
Les actions et commandes
GWT apporte la possibilité de gérer l'événementiel de l'application mais rien n'est prévu pour déléguer et mutualiser le code au sein de classe spécifiques en charge de réaliser des taches. On retrouve ce type de pattern dans les applications Eclipse RCP: les actions et les commandes.
Pour combler ce vide, des classes et interfaces ont été implémentées. Elles sont simples et permettent de cadrer les développements afin de mettre en place une façon de faire qui est réutilisée dans toute l'application.
Les actions étendent une interface et implémentent une méthode execute().
Les commandes sont associées à un gestionnaire de commandes qui permet de déclencher une tache à partir de son identifiant et d'un tableau de paramètre si besoin. Elles nécessitent d'être enregistrée dans le gestionnaire de commande au démarrage de l'application.
Cette façon de faire à été récupérée de la façon de faire Eclipse. Après coup, la notion de commandes devrait être supprimée pour ne laisser que des actions et ainsi simplifier le travail du développeur.
Un exemple d'action:
public class TestAction implements IAction {
public Object execute() {
MessageBox.alert("This is a test message");
return null;
}
} Les vues et éditeurs
Les notions de vues et d'éditeurs présentes dans Eclipse n'existent pas dans GWT. Même si cela donne beaucoup de liberté, encore une fois cela ne donne pas de cadre au développement ce qui peut être gênant quand on créé des applications d'entreprises que l'on souhaitent faire reposer sur un socle de développement stable.
Il faut donc s'improviser créateur de framework graphique pour cette partie, ce qui n'est pas bien difficile si on ne fait que ce dont on a besoin. Pas besoin de coder l'équivalent de JFace pour GWT.
Il faut un peu de bon sens et unifier la façon de faire afin de ne pas s'y perdre par la suite.
Le modèle MVC
Il n'existe pas de pattern pour implémenter une application selon les bonnes pratiques du MVC, il faut encore une fois cadrer soit même ce développement. Pour faciliter la maintenance et la compréhension de l'application, il est préconisé de dissocier le modèle, de la vue et du contrôleur. Le modèle représente l'entité correspondant à l'écran, la vue correspond à la couche uniquement graphique de l'écran et le contrôleur est le gestionnaire qui fait office d'interface de contrôle des données.
A chaque module graphique a été associé un contrôleur, le but est de dissocier totalement la couche purement graphique de position des composants (label, text, liste, combo...) de la couche de contrôle en charge des interactions, du chargement des données, de la partie événementielle, de la synchronisation etc...
Les contrôleurs doivent étendre une classe paramétrée qui les forcent à implémenter une méthode d'initialisation de la couche graphique ainsi qu'une méthode de récupération de la couche graphique associée:
public class TestControler extends MyControler {
private TestUI testUI;
private TestBean testBean;
public void init() {
testUI = new TestUI();
testUI.getTestComponent().setValue(testBean.getTestProperty());
...
}
public TestUI getUI() {
return testUI;
}
}
Le modèle n'a pas d'implémentation particulière, nous utilisons directement les entités métiers (les beans) au sein du contrôleur.
La gestion du dirty
De la même façon que pour le reste, il n'existe pas de gestion du dirty des différentes entités au cours de leur édition. Le dirty permet de connaitre l'état de synchronisation d'un objet par rapport à un référentiel. Soit on gère le dirty par rapport au modèle soit par rapport à la base de données, et nous avons choisi cette dernière possibilité.
Le but est simplement d'indiquer graphiquement les modifications réalisées par l'utilisateur qui ne sont pas synchrones avec la base de données; quand la sauvegarde n'a pas encore été effectuée.
Pour gérer le dirty, nous n'avons pas non plus créé de framework. Mais un développement spécifique à du être mis en œuvre pour gérer cette problématique. Il n'est donc pas réutilisable.
Le databinding
Le databinding n'existe pas nativement dans GWT. En comparaison avec Eclipse RCP, c'est un manque.
Nous avons du gérer manuellement/programatiquement la synchronisation entre la couche graphique et le modèle métier.
Les limitations rencontrées
- Problèmes de fuites mémoires avec Internet Explorer
- To be continued
Un bilan positif
GWT est simple a prendre en main mais il faut être PRAGMATIQUE ! Les développeurs sont totalement libres de faire ce qu'ils souhaitent. Comme rien n'est proposé et que tout est à faire, on peut se laisser tenter par l'implémentation de frameworks techniques sur les différents points de manque. Mais nous ne sommes pas des frameworkers. Notre métier c'est faire des applications répondant à un besoin métier pour un contexte donné.
Un autre bilan se dessine de lui même: Le résultat ! L'application fonctionne et les utilisateurs sont satisfaits !
