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.