Publié par

Il y a 10 ans -

Temps de lecture 10 minutes

GWT Galaxy

Vous avez peut-être assisté au Paris JUG sur GWT et vous vous êtes forcément dit en sortant de la conférence qu’il fallait absolument vous mettre à GWT. En plus, le pas à franchir n’est pas énorme : c’est du Java (ça devrait aller), agrémenté de nombreuses librairies comme dans le monde J2EE, des libraires graphiques qui en jettent sont disponibles… Que d’avantages ! Mais par où commencer ?
Nous allons donc faire un tour d’horizon non exhaustif, mais balayant une grande partie de ce qui est utilisé dans la galaxie GWT : les plugins, les frameworks et les APIs générales et graphiques.

Évolutions du langage

Petit rappel : la toute première version de GWT (1.0) est sortie le 17 mai 2006. Oui, il y a seulement 2 ans et demi ! De nombreuses versions se sont suivies pour arriver à une version 1.4 (fin août 2007) stable et très complète, permettant de démarrer sereinement nos projets.
Mais voilà, fin août 2008 (1 an plus tard, la plus longue période entre 2 releases), la communauté GWT était en ébullition : en effet, l’importante version 1.5 pointa son nez apportant un lot de nouveautés assez importantes.
De nombreux articles nous exposent parfaitement ces nouveautés du langage ; on pourra se diriger sur le Blog de GWT, sur InfoQ ou chez Octo.
Un rapide résumé donnerait :

  1. Enfin du Java en version 5 : annotations, generics, enhanced loop, autoboxing, import static…
  2. Generics ? Donc nos @gwt.typeArgs sont terminés !
  3. JRE Emulation beaucoup plus large avec entre autres les très attendues TreeMap, LinkedHashMap et autres StringBuilder
  4. Compilateur beaucoup plus rapide
  5. Widgets plus complets et plus rapides

En bref : que du bon !

Plug-ins

GWT Designer

Plugin de type WYSIWYG. Il permet entre autres :

  • la création de projet GWT, de module, de service et de librairie,
  • génération du service Async :-) ,
  • la palette de widgets (intégrée dans une vue multi-onglets Design et Source),
  • ajout d’événements et modification des propriétés d’un composant dans les onglets Event et Properties,
  • Compilateur et Hosted Mode intégrés au projet (Builder Eclipse, menu « Run As… »),
  • drag and drop côté Design qui met automatiquement le « Source » à jour.

À noter qu’il faudra, au-delà de la période d’essai, une licence annuelle ou perpétuelle pour continuer à l’utiliser.

VistaFei

Environnement de développement (qui s’appuie sur Eclipse 3.2) intégrant toute sorte de plugins spécialement conçus pour GWT. Il propose :

  • la création de projet, de module (GWTView) et de service,
  • un WYSIWYG (très similaire à celui de GWT Designer) séparant l’onglet « Properties » de la vue « Design »,
  • la génération de code depuis la « GWTView »,
  • l’internationalisation aussi générée.

Son utilisation est gratuite avec la licence « Community Edition ».

IntelliJ IDEA

Un plugin GWT intégré à l’IDE très abouti :

  • création de projet, de module et de service,
  • compilateur de projet,
  • complétion Javascript dans une méthode native (non, vous ne rêvez pas !!!),
  • quick-fix spécifiques GWT (votre code Java est correct mais il ne compilera pas, oubli de l’interface « IsSerializable », utilisation d’une librairie non émulée…), remplacement des @gwt.typeArgs…,
  • navigation rapide entre les méthodes synchrones et asynchrones.

Le plugin est intégré à l’IDE de JetBrains, il faudra donc mettre la main à la poche pour obtenir une licence à moins de vous lancer dans un projet Open Source.

Cypal Studio

Le plugin que tout développeur GWT anti-WYSIWYG a dans son IDE !

  • création de module, de service et d’exemple (sample),
  • compilateur intégré au projet (« builder » Eclipse),
  • lancement du Hosted Mode.

Simple mais efficace, ce produit est disponible gratuitement.

Frameworks

GWT-Maven

De nombreuses commandes maven adaptées à GWT sont disponibles, on notera parmi les plus intéressantes :

  • Lancement du Hosted Mode (Tomcat, noserver, debug…),
  • Compilation GWT,
  • Lancement des tests unitaires GWT,
  • Génération des interfaces pour l’internationalisation,
  • Création de WAR GWT,
  • Création de JAR GWT.

Gilead (anciennement Hibernate4GWT)

L’un des gros problèmes rencontrés au démarrage de GWT est l’utilisation des POJOs Hibernate côté client.
Je vous renvoie vers le très bon article d’Amin Fathallah (Xebia) qui détaille très bien les problèmes rencontrés.
Ainsi, Gilead nous permet d’utiliser nos POJOs Hibernate directement côté client sans aucun mapping Dozer !

Spring

Accessible par les librairies GWT-SL et GWT-WL, il est tout à fait possible d’utiliser Spring dans un projet GWT.
Le principal changement est que les services ne sont plus définis en tant que servlets dans le web.xml. Ils sont remplacés par la classe DispatcherServlet de Spring qui pilotera l’application.
On notera aussi les classes GWTController et GWTHandler, cœur de GWT-SL, permettant de wrapper intégralement nos actions et nos services.

G4JSF

L’adaptation de JSF dans le monde GWT. Même mécanisme que pour le SpringController i.e. que l’on aura des interfaces/classes à implémenter/étendre au lieu des classes GWT standard, les principales étant ComponentEntryPoint et GwtFacesServiceAsync.
Le tutoriel de référence pour l’intégration de JSF avec GWT se trouve sur The Server Side.

APIs graphiques

Le tour d’horizon continue avec les APIs graphiques.
Chaque composant ne sera pas détaillé à outrance, seuls certains seront cités pour donner un aperçu général de ce qui est proposé (détail complet sur les sites officiels respectifs de chaque librairie).

Widgets Core (démo)

Premier réflexe avec tout ce que l’on entend sur GWT : foncer sur la première librairie de composants graphiques à la mode !
Mais n’oublions pas toutefois que GWT propose en standard des widgets haut niveau très complets :

  • Boutons : basique, checkbox, radio, custom…,
  • Listes : basique, suggest, arbre, menu…,
  • Text : basique et riche (à la word),
  • Popups,
  • Panels : décorateur, horizontal, vertical, dock, disclosure, onglet…,
  • Tables : tableau standard et flex.

GWT-Ext (démo)

Certainement la librairie graphique la plus répandue.
Wrapping complet de l’API ExtJS dans sa version 2.0.2.
L’API ne contient donc quasiment que des classes dont les méthodes font une redirection native vers le code Javascript d’ExtJS.
On retrouvera donc tout ce qui se fait dans ExtJS avec des composants très puissants comme :

  • Arbres : éditable, drag & drop (arbre vers arbre ou tableau), tri, checkbox…,
  • Layouts : horizontal, vertical, accordéon…,
  • Liste : basique, listes liées, live (suggest), paginé…,
  • Tableau : éditable, tableaux groupés, JSON ou XML, chargement local ou distant, checkbox…,
  • Formulaire : à onglets, fieldset, multi-colonnes, binding avec un tableau…,
  • Éléments redimensionnables, déplaçables…
  • Widgets bien stylés et des thèmes out-of-the-box

Le point noir reste toutefois la Javadoc, même si celle-ci s’étoffe au fur et à mesure des sorties de GWT-Ext (gros efforts fournis entre les versions 2.0.2 et 2.0.5). Elle reste cependant insuffisante. On pourra tout de même se retourner sur la doc d’ExtJS (puisque ce n’est que du pur wrapping) mais dès que l’on souhaitera aller un peu plus loin avec les composants, il faudra mettre les mains dans le cambouis Javascript.

Ext-GWT (démo)

Le produit de la compagnie ExtJS adapté à GWT.
Ext-GWT prend le parti de tout réécrire en pur GWT i.e. il n’y a aucun Javascript externe, tout est en Java.
Autre atout, l’API utilise les mécanismes internes de GWT permettant une intégration standard des fonctionnalités comme le remote service en Callback, retour JSON, XML… mais aussi du Java 5 (generics, enums et varargs).
On retrouve, sans surprise, les mêmes composants que pour GWT-Ext.
A noter enfin 3 licences disponibles pour le produit (commercial, open source ou revendeur).

Smart-GWT (démo)

Sanjiv Jivan a encore frappé !
Après son wrapping complet d’ExtJS avec GWT-Ext, il s’attaque cette fois-ci à la librairie SmartClient avec sa nouvelle API SmartGWT (nous vous en parlions dans une précédente revue de presse).
Le wrapping est encore une fois très complet : tous les composants de SmartClient sont présents dont :

  • Arbre : colonne bloquée, drag & drop entre de nombreux composants, data binding multiples…,
  • Slider, effects, animations, dialogs, look & feel, …
  • Tableau : filtres, interactions avancées, …
  • Tile (démo),
  • Liste-Tableau, Calendrier (à la outlook), load on demand, …

On retrouvera aussi, et sans surprise, la plupart des composants combobox, radio, field, … d’autres librairie du même type.

Rialto-GWT (démo)

De même que pour Ext-GWT, Rialto-GWT dans sa version 2.0 nous propose d’utiliser GWT 1.5 donc Java 5.
L’API utilise aussi les mécanismes internes à GWT, le Wrapping Javascript est présent mais l’abstraction avec les classes Java rend l’utilisation très simple.
A noter toutefois une Javadoc de composants peu fournie…
Les composants principaux sont proches de ceux d’Ext-GWT.

Tatami (Dojo) (démo)

Encore une célèbre librairie Javascript porté en GWT : Dojo !
Une fois de plus, on retrouve le support de GWT 1.5, des tableaux en tout genre, des sliders, des pickers…

Autres…

D’autres librairies/codes sont disponibles sur la plupart des sites d’informations GWT, on trouvera ainsi quelques wrapper Script.aculo.us (ici ou ) mais aussi des wrapper jQuery (avec entre autre GQuery).

APIs générales

I18N

GWT gère nativement l’internationalisation, donc pas de librairies externes pour cette fonctionnalité.
L’utilisation est simple :

  • un fichier properties contenant toutes nos clés,
  • des interfaces (I18NConstants, I18NMessages…) Java permettant de faire appel à ces clés,
  • une entrée dans notre module.gwt.xml avec si besoin la locale par défaut,
  • une locale pouvant être définie au runtime, dans la JSP ou dans l’URL.

Logs (demo)

Un logger côté client très complet avec différents niveaux de logs : info, warn, debug, error et fatal.
De nombreux loggers sont disponibles comme le ConsoleLogger, le GWTLogger ou bien encore le FireBugLogger.

Google API

Gears, gadgets, Ajax Search et Maps, voici ce que propose la librairie de Google.
À noter que Visualization est en release candidate.

Maths

Émulation de BigInteger et BigDecimal avec un grand nombre de méthodes (add, subtract, multiply, divide, abs, negate, compareTo, equals, toString…).

Et bien d’autres encore !

A chercher/récupérer au besoin ;-)

On pourra rapidement citer GWTEventService (qui permet entre autre de faire du pushing / comet), PureMVC (MVC pour GWT) ou bien encore Goda-Time (Joda-Time pour GWT !).

Conclusion

Ce petit tour d’horizon de la galaxie GWT nous permet de retenir 3 choses : vous avez dit galaxie ?, [Mode gros doutes] Tu penses que c’est possible ? et enfin ça ressemble vraiment à un puzzle cette techno….

Galaxie ? On peut se poser la question dans le sens où, si l’on creuse un peu, on trouve en effet quelques APIs très bien faites… mais elles sont tout de même rares ! Après plus de 2 ans d’existence, on a tout de même l’impression que cette techno se cherche encore et que, du coup, la communauté J2EE n’a pas encore confiance en GWT pour démarrer ses projets. Ce manque d’API robuste ne fera que renforcer cette tendance.

Est-ce possible ? Réponse : Google est ton ami :-) Très peu de sites (comme par exemple onGWT) référencent ce qui se fait en GWT au niveau des outils, des frameworks… Il devient assez laborieux de trouver une API pour un besoin spécifique. N’oublions pas que GWT émule les packages java.util, java.lang et java.io. Suffisant pour certains projets, mais pour de grosses applications de gestion il en faudra d’autres…

Un puzzle ! C’est certainement ce qui ressort le plus des projets GWT. Les librairies se récupèrent à droite, à gauche sur Google, il y en a partout avec peu de référencement… GWT devrait peut-être intégrer directement des APIs reconnues qui ont fait leurs preuves (comme par exemple Java 7 avec Joda-Time)…

Autrement dit, et c’est aussi une des conclusions de GWT in Action, GWT permet de développer très facilement des applications Ajax sans forcément connaitre Javascript (tout en laissant la possibilité de coder directement en Javascript). Il y a bien sûr encore des choses à revoir/améliorer mais le langage est en très bonne voie et les librairies existantes font le travail demandé.

Cependant, devez-vous foncer tête baissée sur GWT car vous démarrez un nouveau projet Web / Ajax et vous ne savez pas quelle technologie choisir (GWT, Flex, Silverlight, JavaFX…) ? Impossible de répondre de manière générale pour tous les projets, cela dépend du back-end existant, des besoins du projet, du temps imparti… Sachez en tout cas que GWT est un excellent compromis entre Ajax, Java et Javascript et que personnellement, sur les projets auxquels j’ai participé, je ne regrette absolument pas son utilisation !

Publié par

Publié par Romain Maton

Après trois années passées chez Improve Technologies, Romain est aujourd'hui consultant Java/JEE chez Xebia. Mission après mission, il s’est forgé une solide expérience en développement Web et logiciel. Il dispose ainsi d'une très large compétence sur l'emsemble de l'ecosystème JEE, que ce soit sur les bonnes pratiques d'architecture, sur les frameworks de développement ou sur les interfaces client riches. Inconditionnel du pair programming, certifié Scrum Master, c'est un fervent disciple des méthodes Agiles. Romain est aussi un contributeur actif de la revue de presse Xebia. Il traite de nombreux sujets tels que RIA, API Java, frameworks ou bien encore Scala.

Commentaire

5 réponses pour " GWT Galaxy "

  1. Publié par , Il y a 10 ans

    Tres bel article. Bravo. Didier

  2. Publié par , Il y a 10 ans

    Merci pour cet article qui m’a fait découvrir pureMVC malheureusement encore en béta. A suivre.

    A note qu’il existe un projet ambitieux lié à GWT => uface qui permettra un jour de databinder à la JFace (http://code.google.com/p/uface/). Actuellement il faut se créer un mini framework maison pour le faire.

    Et je pense qu’une des choses qui rebute les clients potentiels de GWT est le problème de licence ExtJS dont à souffert GWT-EXT. Ce n’est pas rassurant et cela ce comprend. On croise les doigts pour que smartGWT et smartClient ne connaissent de déboires similaires ^^

    Cyril

  3. Publié par , Il y a 10 ans

    Merci pour ce tour d’horizon. J’aimerais toutefois tempérer les ardeurs sur le buzz autour de GWT. Après plusieurs projets GWT (en production), je constate que l’utilisation de ce framework est difficile. Quelques arguments :

    1) GWT n’adresse pas toutes les problématiques. A savoir, l’intégration de la couche de persistance par exemple. Son API est limitée. Du coup, il faut passer par des API tierces (et cela a un coût sur le projet)

    2) Vous devez sans arrêt contenir vos développements dans l’API fournie.

    3) Croire que faire du GWT ne demande pas de compétences Javascript serait comme croire au père Noël. Une bonne maitrise de la manipulation des objets DOM est requise. L’équipe de développement doit au moins comporter une compétence experte dans la matière.

    4) Le comportement entre navigateurs n’est pas uniforme (contrairement à ce qui est annoncé). Alors pourquoi ce delta? Il est probablement produit par le fait que GWT est puissant. Et, plus le framework est puissant, plus on lui en demande.

    5) Le temps de compilation Java->JS s’est passablement dégradé entre la version 1.4 et 1.5. Chaque test vous invite à faire une pause…

    6) GWT est orienté client. Donc, ayez bien à l’esprit que tous les objets transférés côté navigateur sont détachés. Vous devrez donc éventuellement les rattacher à votre session à la mimine (ou bien via une API bioen ficelée)

    Bon OK, je me fais un peu l’avocat du diable là mais je pense sincèrement que GWT n’est pas la solution à tous les problèmes. Je le conseille pour faire évoluer une application existante. Je l’ai notamment intégré dans un ERP web vieillissant et cela a permis d’implémenter des fonctionnalités avancées et de redonner un sérieux coup de jeune à l’application. Pour jouer un peu avec le framework, j’ai également fais un maquette de passerelle VNC (les perticipants d’un certains BarCamp SUN se reconnaitront…). Je l’ai aussi mis en frontal d’un CMS pour enrichir les pages générées à la volée. Là, génial (mais dur à développer).

    En revanche, pour une application de gestion à développer depuis le début, GWT n’est vraiment pas mon choix. Je préfère alors me tourner vers un framework beaucoup plus productif, plus complet, aussi bien écrit, moins puissant en rendu graphique mais mieux adapté au besoin : Apache Wicket. Wicket mérite d’ailleurs qu’on fasse un peu de buzz autour de lui. C’est un magnifique framework, bien écrit, facilement extensible et ne s’appuyant pas massivement sur Javascript (qui est un langage de merde, rappelons le, car mal normé et mal outillé) mais sur Java.

    Bref, encore merci pour votre article mais pensez aussi à rappeler que le ‘tout GWT’ n’est probablement pas rentable pour les entreprise.

  4. Publié par , Il y a 10 ans

    Merci pour cet article, et vos articles en général qui me permettent souvent de conforter ou non mes choix techniques.
    Il y a deux types d’applications:
    – Les applications de gestion (nombreux écrans simples, peu d’interactions dans le client, beaucoup avec un serveur pour la persistance).
    – Les applications de type « Workbench » (peu d’écran, beaucoup d’interactions entre les composants de l’interface, peu d’interaction avec un serveur, Eclipse par exemple).

    J’ai eu à tenter de réaliser une application de gestion avec SWT/JFace, cela a finalement aboutit a une réécriture de l’application avec Wicket car outre les problématiques de déploiement inhérentes aux clients lourd, c’est surtout la maitrise du code qui a été un frein. Eclipse RCP aurait pu être une alternative (découpage en plugins), toutefois, les technologies client lourd restent plus complexes à industrialiser que les technologies Web comme Wicket et surtout ne demandent pas les mêmes compétences.

    Par rapport à cette expérience, je trouve que les frameworks RIA en général (GWT en particulier) souffrent des mêmes inconvénients que les technologies client lourd du monde Java (AWT, Swing, SWT, JFace) en terme de maitrise du code. Ils sont plutôt adaptés pour des applications de type Workbench, encore que je trouve qu’il manque un framework de plus haut niveau comme EclipseRCP dans le monde SWT/JFace. Peut-être que le framework IT Mill (http://www.itmill.com, je ne l’ai pas testé) bâtit au dessus de GWT répond à cette problématique, en tout cas le rendu visuel est plutôt bluffant et le toolkit est sous license Apache 2.0.

    En revanche, comme Alexandre, je pense que les frameworks RIA sont carrément inadaptés pour servir de technologie principale dans la création d’IHM pour des applications de gestion comportant de nombreux écrans. Les frameworks comme Wicket (je l’aime beaucoup celui là), Struts 2, Spring MVC, JSF ? (compliqué celui là), SEAM sont de meilleurs options.

  5. Publié par , Il y a 8 ans

    Merci pour cet article qui résume bien les choses.
    Toutefois je me pose des questions sur la possibilité d’étendre le plugin gwt designer. Est ce possible?
    Merci

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.