Silverpeas recrute

Pour répondre au nombre de projets croissant, Silverpeas recherche une à deux personnes.

Si vous êtes un(e) passionné(e) de technologies web (la connaissance de GWT est un plus) et de développements Java EE. Que vous avez envie de travailler chez un éditeur; Que vous aimez le travail en équipe, l’agilité, vous êtes curieux, ingénieux, et capable d’évoluer dans une architecture technique existante, tout en la faisant évoluer pas à pas. Et que vous avez le sens des responsabilités et du service, ainsi qu'un minimum de 5 années d'expérience.
Alors, n'hésitez pas et postulez.

Votre environnement de développement sera le suivant : Eclipse, SVN, GIT, Jboss, Postgres, Maven, Hudson.
Ce poste est rattaché à la direction des projets basée à Lyon.
Après une formation à l'architecture de la solution, il vous sera demandé de prendre en charge un projet de type web ou intranet/extranet.
La prise en charge sera globale : suivi des charges, étude des besoins, développements, paramétrage et déploiement de la solution. Puis formation et accompagnement du client.

Comment postuler ?

Rendez-vous sur le site de Silverpeas.

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.

Standby but not dead ;-)

As you can see this blog is not very active lately.
This is not due to disinterest, but because of time. I currently work overflowing. And i have a hobby (after computer science), which I neglected too much lately : fishing
So the activity of this blog will slow down...
Nevertheless, this blog is not dead. I continue to follow closely the technological developments and especially the Google technologies.
I would return as soon as you can about the latest GWT from Forplay of GWTQuery of SpringSecurity with GWT-RPC ...

Stay Turned ;-)

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.