GWT 2.4 et après

Avec la version 2.4 de GWT, pas de bouleversements majeurs. Par contre, on constate l'intégration de GWT avec d'autres produits de Google et notamment Android. Pour le moment l'intégration avec Android se borne à la communication au niveau des services rpc, mais il y a fort à parier qu'il s'agit d'une première étape.
Cette version montre que GWT s'ancre un peu plus encore chez Google, sans faire de bruit.

Aujourd'hui en lisant le résumé des contributions sur GWT, je me suis aperçu que GWT allait se doter d'un moyen de debugger le code final (javascript natif).
Jusqu'ici il fallait demander au compilateur de ne pas offusquer le code javascript en sortie pour pouvoir débugger le code final.
Ce problème est le même avec d'autre toolkit comme "Minification", "CoffeeScript" ou "Google Traceur".
Les prochaines versions de GWT vont donc supporter SourceMap, qui est une initiative de Mozilla. Rapidement, je cite :

SoureMap is for all generated code, it keeps a map from input source locations to generated source locations. It uses that map to report errors using the input line numbers and to link to the input source from the console. Support for working with a debugger in the input language will come later (see “Next Steps & Open Issues”).

A noter que Webkit va aussi implémenter SourceMap. Ce qui signifie que l'approche de GWT et consorts pour écrire des applications web est de plus en plus soutenu par les ténors du web. Une bonne nouvelle pour la productivité et la robustesse des applications web.

Elegant way of using REST services with GWT

With GWT it is very easy to call remote services asynchronously. To do this, simply use the GWT RPC mechanism.
However, this solution is not ideal, not in terms of design, but in terms of standard.
Indeed, the RPC mechanism is based on a proprietary data serialization. Even if the serialization format is open, it still proprietary and therefore not interoperable.
In contrast, REST is totally interoperable, but can put off when you are accustomed to the easy call to RPC services.
Well there is an API that brings together the best of both worlds. This little gem is called : restygwt.

At server-side, services are created with the implementation of your choice (for me jersey) : standard.
And at client-side interface, which contains the methods exposed by the REST service. This interface must inherit from the interface and use annotations RestService rest @ Path, @ POST, @ GET, @ PathParam ...

The interface methods should return void and take an extra parameter to handle the callback (MethodCallback ).

Then, simply instantiate the proxy for a rest service call as an RPC service with GWT.create (MyService.class).
The call is done the same way as an RPC service.

Here we see that the call to service rest is greatly simplified thanks to the powerful mechanism deffed binding.

Enjoy.

CSSResources class name obfuscated

Depuis la version 2.0 de GWT, l'optimisation des ressources est prise en charge par ClientBundle. Pour les ressources, on peut utiliser CSSResources.
Grâce au mécanisme de Deffered binding, seuls les styles CSS utiles pour le navigateur sont téléchargés. De plus, les images sont embarquées dans les styles par encodage en base64. Il y a aussi un mécanisme d'encryption des noms de classes. Ce dernier mécanisme est intéressant pour optimiser la taille des styles, et aussi pour rendre opaque le code source de la page.
Cependant, ce mécanisme peut être gênant, notamment si l'on veut autoriser la surcharge des styles grâce à un simple fichier CSS. Ce qui a l'avantage de ne pas avoir à connaitre GWT et à ne pas passer par une phase de recompilation. C'est l'idéal pour confier le relooking d'une application à une web designer.

Mais pour cela, il faut que les noms des classes CSS soient en clair.

En fait, la solution est simple car GWT permet de le faire nativement, mais on peut passer quelque temps pour trouver la solution; Donc la voici : il faut utiliser l'annotation @external dans votre CSS référencé par votre ClientBundle.

Cette annotation sert habituellement à surcharger un style externe dans un fichier CSS référencé par ClientBundle au travers d'un CSSResource (par exemple .gwt-Label). Pour que ce soit possible il faut que le nom de la classe ne soit pas crypté, et il ne faut pas que le compilateur vérifie sa présence dans l'interface CSSResource. C'est ce que fait l'annotation @external.

Mais il est aussi possible d'utiliser cette annotation pour demander à GWT de ne pas encrypter un ensemble de noms de classes. Pour cela, il faut mettre l'annotation @external au début du fichier CSS et non devant le nom de la classe. Il est ausi possible d'utiliser le caractère joker *.

Voici un exemple qui permet de garder en clair les noms des classes qui commencent par .monwidget : @external .monwidget *.

Voila ce n'est pas compliqué, j'espère que cet article vous fera gagner du temps.

GWT DevMode everywhere

The DevMode appeared with GWT 2.0. With DevMode you can run in debug an GWT application. The immediate consequence is the dramatic increase of coding productivity.
It is very easy to use it thanks to the Eclipse Google plugin (Debug as Web application). The application run on embedded Jetty server and the DevMode mechanism is activated (communication between
client and server through a browser extension).

But when the application run in an external server, how to use DevMode ?
For example, a JBoss server that hosts an application based on Struts and improved by GWT components.
Well the solution is pretty simple, just start the GWT module in debug module via Eclipse Google plugin (as usual) and add the following parameter on each call of you pages : gwt.codesvr = 127.0.0.1:9997 (if your server is local).
That's it.

We can therefore use the GWT DevMode in differents technicals contexts : different JEE applications servers (whith JSP, JSF,GSP), but also PHP server PHP or ASP server.

Enjoy, and be productive.

Personnaliser ses cartes avec Google Maps API V3

Introduction

Dans le cadre d'un projet que je suis en train de mener, il y a le besoin de représenter une mappemonde avec un certain nombre de pays à mettre en évidence.
C'est un besoin assez classique pour un site web, mais cela peut s’avérer fastidieux et chronophage.
Pour ma part, j'ai rapidement pensé à utiliser l'API de Google Maps. Mais il me fallait styliser ma mappemonde.
Je devrais afficher seulement certains éléments, en l’occurrence seulement les terres et les mers. Mais il me fallait aussi changer les couleurs des mers et des terres, plus autoriser seulement un contrôle réduit sur la mappemonde.
Enfin, pour mettre en évidence les pays souhaités, ceux-ci devaient être affichés dans une couleur particulière et cerise sur le gâteau avec le changement de cette couleur sur l'évènement "onmouseover".

Google Maps API V3

Depuis peu, la version 3 de l'API Google Maps a vu le jour et Google a déclaré la version 2 comme dépréciée. Je me suis donc penché sur cette API.
Tout d'abord, il existe deux façons d'utiliser l'API, soit directement en Javascript, soit avec GWT via le module "Google Maps 1.1 Library". Malheureusement cette dernière ne supporte pas encore la version 3 de l'API Google Maps. Il faudra donc attendre une mise à jour pour bénéficier du confort de GWT.

Dans ce billet, je vais montrer comment utiliser l'API en Javascript. L'API Javascript est bien documentée et très claire. Donc, la première étape est de charge l'API de la manière suivante :



Le paramètre sensor permet d'indiquer s'il faut utiliser la fonctionnalité de géolocalisation du navigateur.
Ensuite, il faut créé l'objet Map en donnant l'élément du DOM qui va recevoir la carte et les options de la carte.



A partir de là on a une carte qui s'affiche positionnée, avec les contrôles que l'on souhaite. Maintenant comment stylisée ma carte ?
Depuis la version 3 de l'API, Google permet la personnalisation complète des cartes au travers de l'API "Styled Maps". Pour appliquer les styles à notre carte, il faut procéder comme ci-dessous :



Maintenant l'opération délicate est de mettre en évidence les pays souhaités. Pour cela on va utiliser un fichier standard KML pour décrire l'emplacement de mes pays sous la forme de polygones. Les polygones sont décrits point à point. On peut trouver des fichiers KML notamment dans les galeries de Google Earth, sinon il existe des outils en ligne pour créer ses propres fichiers KML.
Pour exploiter les fichiers KML dans notre mappemonde, j'ai utilise l'API "geoxml3". Pour cela, il faut importer les librairies suivantes :



Puis les utiliser de la manière suivante :



Le paramètre "useTheData" est une méthode que j'ai définie et qui sera appelée à la fin du chargement de mon fichier KML. Dans cette méthode, je pourrais notamment gérer les évènements de "mouseover" et "mouseout" sur mes polygones comme ceci :



Conclusion

Voila donc une manière élégante et simple de gérer ses cartes, bien entendu ce que je viens de vous montrer n'est que la base. Il est possible de faire beaucoup d'autres personnalisations et d'imaginer des interactions avec la carte beaucoup plus élaborées.

GWT 2.1 RequestFactory : tour du propriétaire

Avec l'arrivée de GWT 2.1, est apparut une nouvelle API nommée RequestFactory. Le but de cette nouvelle API est de simplifier (un peu plus) les échanges entre le client et le serveur.
Les échanges entre le client et le serveur se faisaient traditionnellement avec le mécanisme RPC de GWT. Hors lorsque l'on utilise un ORM et que l'on est dans une architecture "Domain Driven", on se heurte aux problèmes de sérialisations des entités (qui sont des POJO instrumentés).
Plusieurs solutions existent pour palier ce problème : création d'objets DTO, transformation des entités en vrai POJO (avec la librairie Gilead par exemple).
Néanmoins, la mise en place de ces solutions a un coût et il était regrettable de ne pas avoir une solution intégrée par défaut à GWT.
Désormais, c'est chose faite avec l'API RequestFactory. Alors voyons comment fonctionne cette API.

Côté serveur, on va mettre en place une couche de persistance avec JPA. Pour ma part, j'ai choisi Hibernate comme moteur de persistance. Je ne décrirais pas ici la mise en place de cette couche, car ce n'est pas l'objectif de cet article et de nombreux tutoriaux existe à ce sujet. Donc une fois configurée et nos entités créées, puis mappées par annotations, nous allons pouvoir les exploiter avec l'API RequestFactory.

Les entités seront transmissent entre le client et le serveur, sous la forme d'objets DTO sérialisés en Json. C'est objets sont construit par l'API. Mais il faut décrire un minimum ces DTO. Pour cela, il faut créer une interface par entité à transmettre de la manière suivante :




On remarquera que l'on parle de proxy au lieu de DTO, ce qui n'est pas un hasard car la génération de code par defferd binding est très présente (comme dans les mécanismes RPC). D'autre part, il est possible d'utiliser l'API Bean Validation (JSR 303), nous verrons plus loin comment gérer la validation des entités.
Maintenant, on va créer des contextes d'échanges et leur fabrique (RequestFactory) pour le client.

Les contextes d'échanges sont des interfaces qui héritent de RequestContext, elles permettent d'exposer les méthodes statiques de services (un service métier, une DAO, ...) sous la forme d'un objet Request. Elles permettent aussi d'exposer des méthodes d'instance d'objets (une entité, un DTO) sous la forme d'un objet InstanceRequest. Voici deux exemples qui illustre mes propos :





Maintenant il faut créé la fabrique comme ceci :



Désormais tout est prêt, et il faut effectuer les appels côté client. Tout d'abord, on va instancier la fabrique précédemment créée, puis la lier à un EventBus, comme ceci :



Ensuite on va pouvoir récupérer des contextes d'échanges (RequestContext) et faire nos traitements. Voici un exemple de création d'un proxy pour l'entité Employee et l'appel à une méthode statique d'une DAO qui aura en charge de faire persister l'entité :



On voit dans cet exemple qu'il est possible d'avoir un callback sur l’exécution effective de la requête émise par la méthode fire. La méthode onViolation permet de récupérer toutes les violations levées par la validation de l'entité côté serveur.

L'exemple suivant montre comment faire le même traitement mais en invoquant une méthode sur l'instance de l'entité que l'on est en train de créer côté serveur :



C'est là que l'on commence à toucher du doigt le potentiel de cette API ! Je vous laisse le soins d'imaginer comment il est possible de l'exploiter. Voici donc une API qui permet d'augementer encore le rendement les développements GWT , couplé avec les CellWidget cela peut s'avérer redoutable d'efficacité.
Mais cela fera l'objet un d'autre article. Il faudra explorer aussi l'utilisation de cette API avec un conteneur comme Guice ou Spring.

NB :

Lors de mes premiers pas avec l'API RequestFactory, j'ai été confronté à plusieurs problèmes. Le premier est la non compilation des classes avec les annotations @ProxyFor et @Service. Ce problème est lié au plugin Eclipse GWT Designer, le seul contournement que j'ai trouvé est de désinstaller le plugin... Espérons que les prochaines mises à jour du plugin réglera ce problème. Le second problème que j'ai rencontré est de bien veiller à utiliser l'annotation @Id du package javax.persistence dans les entités JPA et ne pas utiliser l'annotation @Id du package com.google.gwt.requestfactory.shared.

GWT the Google master piece

Le compilateur GWT est très puissant et modulaire. J'ai déjà parlé du mécanisme de deffered binding qui permet de générer ou substituer du code Java avant sa compilation en Javascript.
Mais il existe un autre moyen d'exploiter le compilateur, il s'agit d'exploiter les Linkers.
Les linkers interviennent après la compilation et sont en mesure de modifier les fichiers générées pour adapter l'application à son contexte d’exécution pas exemple. Le linker par défaut est IFrameLinker, ce qui a pour résultat de générer une iFrame cachée. GWT propose d'autres linkers : SingleScriptLinker, XSLinker, SymbolMapLinker, SoycReportLinker.
Mais l'on peut trouver un linker pour créer des extensions pour Google Chrome, ou FireFox.
Il est bien entendu possible de créer d'autres linkers personnalisés. Alors on peut imaginer de nombreuses adaptations/intégrations pour le code GWT (Portlet, Gadget, Native client, Chrome OS, ...).
C'est pourquoi GWT semble devenir de jour en jour la couche d'abstraction générique de Google. GWT pourrait donc devenir la pièce maîtresse de Google au niveau du développement de ses applications/services.

Reparlons-en dans deux/trois ans ;-)

Gestion des skins et ClientBundle

With GWT 2.0 ClientBundle appeared. This mechanism is very interesting because it optimize the loading time of a web application resources, such as CSS files, images files, and many others.
This mechanism also allows typing of CSS using Java interfaces to access styles; The compiler verifies the existence of CSS classes used.
To do this, simply declare an interface that inherits CssResource and define methods corresponding to names of CSS classes.
To inject the CSS in the HTML page is then necessary to generate an instance of the CSS resource through : GWT.create (MyCSSResource.class). Then call the method "ensureInjected ()" on this instance.

This mechanism works very well, now let us see how to manage skin with this mechanism.

The idea is to change style sheet dynamically. The HTML page elements remain unchanged and refer to the same CSS classes.

For this, we can use the inheritance mechanism between interfaces CssRessources to structure CSS skins. To have identical CSS class names, do not forget to add the annotation @Shared on parent interface.

To inject the selected CSS skin, do not use the method "ensureInjected ()" because it controls the injection of resources and CSS will injected only once. Should be used instead : StyleInjector.inject (cssStyle.getText ())

But not to overload the page, we must removing the contents of the previous CSS, stored in the header of the page.

Here an example of code :

To make dynamic discovery of skins, we can use a generator (see previous article).

Stay tuned

GWT and reflexion API

As you probably know, GWT does not emulate the reflection API of Java. It is a conscious choice by Google, which is motivated by the performance degradation induced by the introduction of mechanisms for reflection (not mentioned the lack of control of code).
However, it is sometimes useful to use the reflection API. Recently, I was confronted with the establishment of a GWT application that handles plugins. These plugins must be discovered dynamically. In Java you would use a scan packages with the reflection API or with Spring IOC. But in my case it is not possible because there are plugins that are client side, so that must comply with the constraints of GWT.

So how can i do that ?

To overcome this problem, the GWT team has developed the mechanism called "deffered binding" that allows to perform operations before the compilation of Java code in Javascript.
For my problem, I used a Generator. The generator, as its name suggests will allow to dynamically generate Java code before compiling for a given type.

What is interesting is that at this stage, it is possible to use any Java API that is desired because the generator is running in a JVM.
We can therefore use the reflection API. Furthermore, the scanning of packages is possible because the classes corresponding to the project source code is loaded into the classloader.
Once obtained the list of plugins (a plugin implements an interface call "Plugin"), it must generate a list of plugin object with an object through PluginFactory generator.

On this occasion, I also discovered a very nice API to list the packages in the ClassPath: classpath-explorer

So here we are an elegant technique to develop a plugin mechanism with GWT. The only drawback to this method is that for the addition of a plugin, it is necessary to recompile the project, which is not needed with Java plugins (like Eclipse plugins).

GWT 2.1 : les nouveautés

Depuis le 02/07/2010, GWT 2.1 milestone 2 est disponible.
La première release devrait être mise à disposition par Google pour la rentrée en Septembre. Mais qu'apportera cette nouvelle version, faut-il attendre cette prochaine version avant de démarrer le développement d'une nouvelle application ?
C'est à ces questions que je m'efforcer de répondre.

Ce qui est marquant avec cette nouvelle version, c'est la quantité de code produite par l'équipe de Google. Car entre la version 2.0.3 et la version 2.1, il y a environ 20 % de code en plus au niveau de la framework (gwt-user).

Tout d'abord, cette nouvelle version apporte de nouveaux composants orientés données (data presentation widgets). Il y a par exemple le composant liste paginable.
En fait, il s'agit de l'apparition des composants avec un modèle associé. Il y a un modèle pour les listes, pour les listes paginées, pour les arbres, pour les composants avec sélection simple ou multiple.
On voit aussi l'apparition d'une gestion plus fine des tableaux, avec la possibilité de spécialiser des cellules (cellule de saisie pour un certain type de données, affichage selon un format...).
Cette nouvelle version devrait apporter des solutions à des problématiques communes, avec notamment une implémentation du pattern "service place", mais aussi une implémentation du pattern MVP (Model View Presenter) avec un système de validation des formulaire déclaratif au niveau de l'UIbinder.
Il y a même un mécanisme de synchronisation des objets entre client et serveur (valuestore). Ce mécanisme est plutôt original, et alimente de nombreuses discutions aux seins des contributeurs, il n'est donc pas certain que ce dernier soit présent dans la release 2.1.

Ensuite, il y a de nombreuses classes et mécanismes utilitaires qui seront ajoutés, tel que la compression des échanges RPC avec l'algorithme gzip. Des classes utilitaires de gestion des expressions régulières font leur apparition.

Et enfin, un un système de logs côté client est intégré afin d'exploiter l'émulation de la stack trace. Ce système de logs ressemble beaucoup au module gwt-log créé par Fred Sauer.

Avec cette nouvelle version, on constate que l'effort de l'équipe GWT pour rendre de framework encore plus mature est constant.
Alors faut-il attendre la version 2.1 de GWT avant de démarrer un nouveau développement avec cette technologie ? Et bien, que non. Il faut bien choisir les modules complémentaire, par exemple pour la gestion des logs. La mise en application de patterns comme le MVP ou le "service place" structurera l'application et facilitera la migration vers la future implémentation de GWT. Vous avez donc bien compris que Google s'inspire des différents projets maintenus par la communauté, mais aussi des retours d'expériences sur GWT.
La dynamique de Google est forte sur le projet GWT, il faut donc s'assurer de rester agile. En s'informant (Google donne beaucoup d'informations) et un peu de recule, les orientations et choix à faire se dégagent.

Pour vous donner un avant goût de la suite, la version suivante de GWT (la version 2.2) devrait apporter des évolutions non négligeables, avec notamment, le début de prise en compte de l'HTML5.

Stay tuned.

Lyon en 3D

J'utilise très souvent Google Maps et notamment Google Street View. Il y a environ six mois je découvrais que la couverture de Google Street View en France avait progressé de manière impressionnant (plus de 70% du territoire est couvert). Ce service est tellement pratique et accessible, que j'en avais oublié Google Earth. Récemment, j'ai relancer "par hasard" Google Earth. Je connaissais la fonction "Bâtiment 3D" et l'avais donc précédemment activé. Et là, j'ai eu la surprise de découvrir la ville de Lyon entièrement modélisée en 3D.

On peut zoomer sur les façades, changer l'angle d'inclinaison, tourner autour des bâtiments. La précision est remarquable et le nombre de bâtiments modélisés est tout simplement énorme. Par contre, pour profiter pleinement de cette fonctionnalité il faut avoir une bonne connexion internet (une connexion fibre optique devrait pleinement s'exprimer).

Strong typing in web application

Lorsque je s'écrire un programme, j'ai horreur d'avoir des surprises au moment de l'exécution du programme (at runtime). Pour palier à ces mauvaises surprises, il faut d'abord compiler le programme. Celui-ci va effectuer des vérifications et donc éviter d'avoir de mauvaises surprises à l'exécution du programme.

Cela dit, pour assurer une vérification optimale de la part du compilateur, il faut avoir recours à un typage fort.

Maintenant, imaginez que l'on puisse appliquer ces principes avec des  développements web. Car lorsque l'on développe une application web, c'est généralement tout l'inverse. En effet, le web est traditionnellement une technologie runtime (ex : PHP, JSP, ASP, javascript, ...). Qui n'a pas eu a faire à l'erreur HTTP 500 ? Ou bien à des mises en formes cassées suite à une réorganisation des fichiers CSS ?

Vous l'avez compris, les développements web sont souvent délicats à tester car nous manipulons plusieurs technologies runtime.

En plus, des bugs générés par cet état de fait, il y a une autre incidence à cela; J'ai nommé la productivité, c'est pourquoi le scaffolding a le vent en poupe ces derniers temps. Le code généré est fiable et vite obtenu. Mais cette technique n'est qu'un pisalé, car inévitablement il faudra retoucher le code généré un moment donné, et là on retrouve les problèmes que j'ai précédemment cité.

Alors, existe-t-il une solution qui permet de développer des applications web, avec une compilation préalable ? Et bien oui, il s'agit de Google Web Toolkit. Depuis la version 2.0 de GWT, il est possible de compiler l'HTML et le Javascript, mais aussi le CSS  et les ressources (images, textes, documents, ...).

Et même en utilisant le UI-binder, le compilateur garantie que toutes les vérifications nécessaires seront réalisées. Par exemple, si un style CSS est référencé dans un composant et qu'il n'existe pas, alors le compilateur signalera une erreur. Avec ce simple exemple, on comprend très vite que GWT permet non seulement de réaliser des applications fiables, mais aussi de manière rapide.

MyColocation

Aujourd'hui est en grand jour (pour moi), je viens de mettre en ligne la première version de mon application "MyColocation". L'objectif de cette application est de permettre la gestion quotidienne d'une colocation. Dans cette version je me suis essentiellement attaché a gérer les tâches qui incombent aux colocataires. Cela signifie, identifier les tâches, mais aussi les répartir de manière collaborative, et les suivre.

Du côté de l'ergonomie, j'ai essayé de rendre l'application la plus simple. J'ai donc naturellement eu recours au Drag&Drop.

Cette application est entièrement écrite avec GWT 2.0.3 et les API de GAE 1.3.1. Je trouve que mes développements ont été relativement productifs.

Cela est dû à la productivité engendrée par GWT 2 (Uibinder et Dev mode), mais aussi à la grande facilité d'utilisation d'App Engine. En effet, il est possible de développer et tester localement son application, avant de la déployer sur le Cloud. La gestion des versions est plutôt bien pensée et la console d'administration est plutôt riche.

Le seul point négatif que j'ai pu noter, est les limitations imposés par Google au niveau du DataStore et en particulier le support limité de JPA. L'apparition récente des curseurs, me laisse espérer que ces limitations vont progressivement disparaitre.

Pour vous faire une idée de cette application, je vous invite à vous rendre à l'adresse suivante : mycolocation.

N'hésitez pas à me faire des suggestions d'améliorations, je ferais mon possible pour en tenir compte.

GWT 2.0.2 est là : Google très réactif

Depuis la sortie de la version 2.0 de GWT, on assiste à une adoption de la plus en plus large de GWT en France et les migrations de GWT 1.x à 2.0 se succèdent. Dans le même temps, tout un écosystème s'est mis en place autour du toolkit : plugin eclipse, speedtracer, plugin browser for devmode, ...
D'autre part, la réactivité de l'équipe Google est de plus en plus visible : depuis la version 2.0 sortie en décembre 2009, deux versions correctives ont vues le jour (version actuelle 2.0.2). Et Google ne compte pas s'arrêter en chemin; Pour preuve, Bruce Johnson (le responsable du projet GWT), a fait des appels du pied récemment à la communauté, pour que des développeurs rejoignent l'équipe GWT  à Atlanta.
Tout ces éléments me font dire, que GWT est en train de monter en puissance et de s'industrialiser. Google vise clairement le marché des entreprises avec GWT, comme il est entrain de le faire avec sa suite Google Apps.
Cela promet, donc une année 2010 riche en nouveautés et en projets d'entreprise.


Pour ma part, je travaille actuellement sur un projet GWT App Engine dont je vous donnerais des nouvelles très bientôt.

"Wicket with GWT" and not "GWT vs Wicket"

Often, we compare Wicket vs GWT because they are both component-oriented. But the comparison stop there, because their approaches are opposed. Wicket is oriented server : the server generates web page. While GWT is client-oriented : the client is downloaded and communicates with the server.

Wicket ajax components are based on javascript libraries. This does not facilitate the development and maintenance of these components (using multiple libraries, the problem of multi-browser compatibility, web page size, ...).

GWT applications are oriented RIA, which is quite different from a "classic" web application and the user may be a little disoriented ("back / next" navigation, refresh browser, single mode page ...).

So why not combine the power of GWT with that of Wicket to create original web applications ?

Here is an article which proposes an architecture for combining the best of both worlds. Unfortunately, since 2008 it does not appear to have been implemented. In fact we can solved this equation with only GWT.

The single page mode that can disrupt the user. For this it is possible to create HTML pages which embed the javascript application generated by GWT. Each page is composed of area identified by ids, which are injected components of the GWT application (using RootPanel.get(id).add(myComponent)).

Navigating between pages is provided by :

public static native void setWindowHref(String url)/*-{ $wnd.location.href = url; }-*/;

In this configuration, the client becomes stateless (like a "classic" web application). But the components are more dynamic (as an application RIA). This approach may be useful in some cases to meet the requirements of users and do not change their habits.

GWT incubator integration roadmap

Depuis ce début d'années, Google réfléchit à la suite de GWT 2.0. Bruce Johnson sonde la communauté afin de connaitre les attentes des développeurs.

Et aujourd'hui on commence à avoir des informations sur la roadmap de GWT 2.1 et 2.2 (voir ici). Bien entendu pour le moment il n'y a rien d'officiel. Cela montre tout de même que l'équipe qui développe GWT ne s'endort pas sur se lauriers (après l'énorme travaille fournit pour passé de la version 1.7.1 à 2.0) et que GWT est plus vivant que jamais.

Pour ma part, je suis particulière sensible à l'intégration d'un système de validation des formulaires. J'espère que ce système sera conforme à la JSR-303 et qu'il permettra de tirer parti de la validation des formulaire avec HTML5 (si le navigateur le support).

Affaire à suivre...

Affiches publicitaires de Google Chrome

En ce début d'année 2010, on assiste à l'apparition d'affiches publicitaires pour Google Chrome, notamment dans le métro Parisien.

Je pense que c'est la première fois (en France) que Google procède de la sorte et change sa façon de faire de la publicité. Jusqu'ici le seul média utilisé par Google était le Web.

Bien sûr il y a les spots publicitaire sur les chaines de télévision pour les mobiles Androîd, mais il s'agit de publicité indirect car c'est les constructeurs de mobile qui sont a l'origine de ces publicités.
Mais cette fois-ci il s'agit bien d'une publicité "non électronique" pour une produit de la société Google.
On peut donc se poser la question : pourquoi ce changement ?

Cela ne présage t-il pas de changements plus profonds ? Que vont apporter ces changements ? Une nouvelle aire pour Google? Pour les internautes ? Pour l'innovation informatique ?

En tout cas, cela ne laissera personne indifférent et cela va faire couler beaucoup d'encre...

Temps de compilation GWT

Une de faiblesse de GWT est le temps de compilation. En effet, les temps de compilations augmentent au fils des  développements et cela se révèle pénalisant à terme. L'équipe qui développe GWT l'a bien comprit et ne cesse d'optimiser le compilateur pour obtenir des temps de compilation plus courts. Entre la version 1.6.4 et la version 1.7.1 les temps de compilation ont été réduits de manière perceptible pour le développeur. Avec la version 2.0 et le nouveau "dev mode", le développeur gagne encore en réactivité.
Et les prochaines versions de GWT vont très certainement aller dans ce sens. 
En attendant, il est possible de "tuner" le paramétrage du compilateur pour obtenir de meilleurs résultats.
Tout d'abord, le paramétrage de la mémoire de la JVM est important (ex : -Xmx512m), car si le compilateur manque de mémoire il sera ralenti de manière significative.
D'autre part, les performances de votre CPU vont grandement influencer celles du compilateur. Si votre CPU est multi core alors il est possible d'utiliser le paramètre "-localWorkers n" avec n qui est le nombre de workers désirés.
Un paramétrage efficace consiste à avoir autant de workers que de cores. Idéalement, il faudrait avoir autant de cores que de permutations et que de workers.


Prenons un exemple concret. J'ai une application GWT d'une certaine taille (environ 36000 lignes de codes), qui occasionne 5 permutations. Je compile l'application sur une machine Intel Core 2 Duo. Voici les différents résultats que j'obtiens :

Paramètres		Temps de compilation
-Xmx256m	-localWorkers 1	109 secondes
-Xmx512m	-localWorkers 1	94 secondes
-Xmx512m	-localWorkers 2	81 secondes
-Xmx640m	-localWorkers 2	79 secondes

Avec ces résultats, on voit bien que ces deux paramètres influencent nettement le temps de compilation GWT. N'hésitez pas a les utiliser, car dans un projet chaque seconde compte.


En complément, vous pouvez gérer les permutation que le compilateur effectue. Pour cela vous pouvez spécifiez au niveau du module GWT (fichier *.gwt.xml) les navigateurs cibles, comme ceci :


<define-property name="user.agent" values="safari,opera"/>


NB : Avec GWT 2.0, un nouveau paramètre "-draftCompile" permet de demander au compilateur de ne pas procéder aux optimisations et donc de gagner du temps à la compilation.

Deep into GWT rpc request

By default, rpc calls doesn't haves timeout.
It is a problem when the network connection between the client and the server is interrupted, because the client rpc proxy waits indefinitely for a response that will never come... The management of the timeout depends on the version of GWT.


Management of the timeout with GWT version 1.x (tested with 1.6.4, 1.7.0 and 1.7.1) :


The first naive idea is to use the Timer class. This technique is not very elegant, because it monopolizes client side resources, and do not release http connection.
The problem is that RPC connection is a persistent http connection, and browser has a maximum number of http persistent connection per server.
So to solve this problem, we must be attentive to the interface of the asynchronous RPC service.


Typically service rpc methods are reflected in the asynchronous interface, with an additional parameter for callback and void return. But the proxy generator authorizes asynchronous  methods to return different kind of object : Void, Request and RequestBuilder.
In our case, we will use the object RequestBuilder, because we can defined a timeout with the methods "setTimeoutMillis". When an asynchronous  methods return a RequestBuilder object, for calling the remote method, we must explicitly call the "send" method of the RequestBuilder object. With this approach, when the timeout is reached, an RequestTimeoutException is throwed and the callback onFailure method is called.


Management of the timeout with GWT version 2.0 :


With GWT 2.0, it is possible to define its own RpcRequestBuilder class which define the timeout and will be used by the rpc proxy for asynchronous call of RPC service. Here's the code to implement :

Then, we must affect RequestBuilder to the rpc proxy, like this :

GWT exception management

To handle exceptions in GWT, like in java we use blocks try / catch / finally.
Unfortunately, runtime exceptions can be forgotten if we do not use a try / catch / finally overall. 
GWT programs are highly asynchronous, and this characteristic force us to declare many blocks try / catch / finally. It is therefore not immune to a NullPointerException ...


Fortunately GWT provides a special handler to catch exceptions not caught : UncaughtExceptionHandler.
Once implemented the method "public void onUncaughtException (Throwable e)"
receive all the exceptions not catched. This solution is simple, effective and elegant, can be implemented afterwards without impacting the structure of the program.