insideIT.fr : le blog des architectes IT de SFEIR

GWT 2.1 vient de sortir en version finale, voici les nouveautés apportées par cette version :

• Data Presentation Widgets
• MVP Framework (Activities and Places)
• RequestFactory
• Editor
• Server-side Speed Traces
• Logging
• Safe HTML

Détaillons un peu ces nouvelles fonctionnalités :

Data Presentation Widgets

Ce nouveau framework permet de construire des tableaux dynamiques (liste, arbres). Ces composants peuvent afficher un très grand nombre de données, car il va construire les données en minimisant les appels au DOM de la page.

MVP Framework (Activities and Places)

Depuis 2 ans, Google pousse le design patern Model View Presenter (MVP) grâce à une présentation faite par Ray Ryan à Google IO ainsi que deux articles :

http://code.google.com/intl/fr/webtoolkit/articles/mvp-architecture.html

http://code.google.com/intl/fr/webtoolkit/articles/mvp-architecture-2.html

De nombreux frameworks ont permit d'implémenter ce nouveau design pattern :

• Gwt-Platform
• Mvp4g
• Gwt MVP

A la différence des frameworks précédents, la version de GWT 2.1 utilise une autre terminologie, en voici un petit lexique, et explication.

Vue

Tous d'abord, la notion de vue n'existe plus, une vue est un simple widget GWT ou plutôt un composite qui peut être une classe UiBinder.

La nouveauté c'est que tous les widgets Gwt implémentent maintenant l'interface IsWidget, qui demande une seule méthode Widget asWidget();

Maintenant une vue dont l'implémentation est un simple Widget peut être définie par une interface, tout en pouvant ensuite l'ajouter dans un conteneur.

Une vue étend une interface du Presenter qui permet à celui-ci de communiquer avec la vue.

Activité (Presenter)

Un Presenter se nomme maintenant une activité (Activity), et s'occupe de toute la logique métier de l'écran.

Un Presenter peut implémenter une interface venant de sa vue pour simplifier la gestion des événements avec UiBinder, c'est à dire qu'on crée dans la vue la méthode onClick accompagné de l'annotation @UiHandler, dans laquelle on appelle une méthode du Presenter (Activity) qui gérera ensuite l'action. L’ancienne technique avait pour principe de définir une méthode dans la vue (getter) qui retourne une interface permettant d’ajouter un Handler par le Presenter (i.e. HasClickHandlers).

Une activité doit implémenter deux méthodes :

• start(AcceptsOneWidget containerWidget, EventBus eventBus) : Appelé lorsque l'activité doit s'afficher
• onStop() : Appelé lorsque l'activité doit disparaître (lors qu'une autre activité viendra la remplacer ou que l'on quite la page)

Deux autres méthode doivent aussi être implémentées :

• mayStop() demande un message à afficher si on veux demander à l'utilisateur si il veux réellement changer de page (indiquer qu'ils n'a pas sauvegarder un formulaire par exemple). Il suffit de retourner null si l'activité accepte le changement de page.
• onCancel() : Appelé si l'activité n'a pas encore eu le temps d'être afficher et qu'elle doit déjà être remplacer par une autre activité.

Remarque: En étendant la classe AbstractActivity, seule la méthode start() doit être implémentée.

AcceptsOneWidget est aussi une nouvelle interface ajoutée à Gwt laquelle est implémentée par SimplePanel, et dans laquelle la vue doit être ajoutée. Cela évite de devoir utiliser l'interface HasWidgets ainsi que le Presenter fasse un clear() avant de faire un add() pour remplacer le widget composant la vue principale.

ActivityManager

L'ActivityManager, c'est un peu le pendant de l’AppControler (l'autre partie est remplacée par le PlaceController), car il s'occupe de changer les activités affichées lorsqu'une nouvelle page doit être affichée. Cette classe est directement implémentée par GWT 2.1. Chaque zone pouvant afficher des activités aura son propre ActivityManager.

Places

C'est là, la grosse nouveauté de ce nouveau framework MVP, car on ne retrouve pas cette information dans les autres frameworks MVP. Pour ceux qui connaissent la programmation Android, une Place a le même rôle qu'un Intent. Une Place représente le lieu où l'on se trouve, s'est à dire la page (activité) qui est affichée. Changer de page ou d'activité revient à changer de Place, d'où la méthode goTo(Place newPlace) qui est dans le PlaceControler.

Le PlaceControler représente ainsi la deuxième partie de l'AppControler, présenté par les anciens articles. A la différence de l’ActivityManager, le PlaceController est unique pour l’application.

Il ne peut pas y avoir deux Places affichées simultanément. Une Place peut contenir des données, c'est une simple classe à créer qui étend Place où l'on met les propriétés que l'on veut.

Pour qu'une Place puissent être utilisée comme URL (et ainsi utiliser les fonctionnalités précédent et suivant du navigateur), il faut utiliser le PlaceHistoryMapper qui permet de transformer une Place en String et vice versa.

Gwt propose de générer automatiquement cette classe. Il nous faut alors créer un Tokenizer pour chaque place qui va sérialiser et désérialiser les attributs d'une Place de la façon que l'on veut. Il va ensuite afficher dans l'URL le nom de la Place (nom de la classe pouvant être redéfinis par l'annotation @Prefix("")) La classe PlaceHistoryHandler s'occupera ensuite de changer l'url et la gestion de l'historique automatiquement.

ActivityMapper

Cette classe permet de faire la conversion entre une Place et une Activity. Elle s'occupe d'instancier l'Activity pour une Place donnée. C'est à nous de la créer mais avec Gin, cela peut se faire facilement.

EventBus

C'est un bus d'événement, il permet de faire communiquer tous les composants d'une application avec les autres applications. L'ancien HandlerManager n'existe plus, l'interface EventBus est désormais utilisée. Une implémentation simple existe : SimpleEventBus. Attention, une activité doit ajouter ses évènements dans le "start" car une fois qu'elle est supprimée les événements sont retirés automatiquement.

Model

Le model est implémenté par la RequestFactory qui permet de faire transiter des entities JPA /JDO entre le server et le client. Il apporte automatiquement les méthodes nécessaires pour construire un CRUD (Créer, Lire, Mettre à jour, Supprimer). RequestFactory n'a pas pour vocation à remplacer RPC et peux être utilisé indépendemment. Seules les données modifiées de l’entité transiteront sur le réseau.

Editor

Apporte un système de binding entre les objets java et les représentations graphiques en particulier pour créer les formulaires de création et de modification. Plus d'informations Vous pouvez retrouver la documentation officielle avec un projet d'exemple :

http://code.google.com/intl/fr/webtoolkit/doc/trunk/DevGuideMvpActivitiesAndPlaces.html

et voici quatre autres articles qui expliquent le fonctionnement des Places et Activities :

• GWT 2.1 Places
• GWT 2.1 Places – Part II
• GWT 2.1 Activities
• GWT 2.1 Activities – nesting? YAGNI!
• MVP Factory Exemple

Server-side Speed Traces

Les informations de performances venant du serveur (Google App Engine ou Spring TC Server) peuvent maintenant être affichées dans l'outil Speed Tracer.

Logging

Il existait déjà Gwt-Log qui a été maintenant intégré directement à GWT 2.1. On utilise l'Api standard Java pour logger (java.util.logging). Par-contre la configuration de logging se fait dans le fichier .gwt.xml

# In your .gwt.xml file
<inherits name="com.google.gwt.logging.Logging"/>
# To change the default logLevel
<set-property name="gwt.logging.logLevel" value="SEVERE"/>  
# To disable logging        
<set-property name="gwt.logging.enabled" value="FALSE"/>      
# To disable a default Handler      
<set-property name="gwt.logging.consoleHandler" value="DISABLED"/>  

# In your .java file
Logger logger = Logger.getLogger("NameOfYourLogger");
logger.log(Level.SEVERE, "this message should get logged");

Les logs peuvent être ensuite affichés de différentes façons,

• SystemLogHandler - Ecrit dans la sortie du mode de développement de GWT
• DevelopmentModeLogHandler - Utilise l'ancienne méthode GWT.log (les logs ne sont visibles qu'en mode développement)
• ConsoleLogHandler - Ecrit dans la console Javascript (Firebug ou console Chrome)
• FirebugLogHandler - Ecrit dans la console Firebug
• PopupLogHandler - Affiche les logs dans une popup
• SimpleRemoteLogHandler - Envois les logs par un RPC où l'on peut logger ensuite sur le serveur.

Safe HTML

Safe HTML permet de filtrer du texte pour protéger le HTML qui le contient et éviter les injections XSS. Il fonctionne comme un StringBuilder, mais peut échapper automatiquement les caractères spéciaux. Un système de template permet d’écrire du code HTML facilement en utilisant un mécanisme similaire aux Messages mais en protégeant le code HTML.

public interface MyTemplates extends SafeHtmlTemplates {
   @Template("<span class=\"{3}\">{0}: <a href=\"{1}\">{2}</a></span>")
   SafeHtml messageWithLink(SafeHtml message, String url, String linkText,
       String style);
 }

 private static final MyTemplates TEMPLATES =
     GWT.create(MyTemplates.class);

 public void useTemplate(...) {
   SafeHtml message;
   String url;
   String linkText;
   String style;
   // ...
   InlineHTML messageWithLinkInlineHTML = new InlineHTML(
       TEMPLATES.messageWithLink(message, url, linkText, style));
   // ...
 }

Voilà un rapide tour d'horizon des nouveautés de GWT 2.1, d'autres articles suivront pour expliquer plus précisément certains points. Ces nouveautés une fois maitrisées et utilisée sont vraiment puissante et apporte encore plus de simplicités à la fois pour le développeur mais aussi pour l'utilisateur.