Silverpeas 5.10

Presque tout le monde a fait sa rentrée, Silverpeas y comprit; Bien que cet période estivale a été studieuse pour les équipes Silverpeas.

Grâce à ses efforts, la version 5.10 de notre produit a été rendu disponible.

Pour ceux qui ne connaissent pas Silverpeas, il s'agit d'une solution collaborative qui permet de bâtir de intranet/extranet et des sites web. L'idée est d'avoir un référentiel d'informations commun afin de permet la collaboration entre différents acteurs. Une gestion des droits fine permet de contrôler l'accès aux informations.

Une trentaines d'applications prêtes à l'emploi sont disponibles en standard dans Silverpeas et peuvent être installées autant de fois que nécessaire et configurées de manière indépendantes; Et tout cela en quelques cliques.

Bien entendu, le visuel de Silverpeas est personnalisable afin de coller à votre identité.

Plusieurs niveaux de personnalisation sont possibles (images / CSS / HTML).

Silverpeas est une solution libre et ne demande qu'à être enrichie par de nombreux contributeurs.

La version 5.10 apporte une évolution majeure attendue par une grande partie de la communauté est

disponible : la synthèse des notifications. Cette nouveauté va permettre aux utilisateurs de maîtriser la fréquence à laquelle ils reçoivent les notifications par e-mail. Plus qu'une simple concaténation, la synthèse regroupe par contribution les différents faits générateurs des notifications.

Le présentiel, une autre fonctionnalité importante, voit le jour avec Silverpeas v5.10. Il permet de savoir immédiatement si un utilisateur est connecté. Couplé au présentiel, le zoom offre la possibilité de rentrer immédiatement en contact avec cet utilisateur par messagerie instantanée ou par notification, de l'inviter à rejoindre ses contacts, de consulter son profil... Avec cette évolution, Silverpeas poursuit son objectif de recentrer l'utilisateur au cœur de sa plate-forme.

Les administrateurs et gestionnaires d'espace peuvent désormais réorganiser plus rapidement les espaces grâce à la nouvelle opération Couper l'espace qui permet de le déplacer facilement.

Certaines applications s'enrichissent comme l'agrégateur RSS ou l'almanach. D'autres ont bénéficié d'améliorations ergonomiques. C'est le cas de Vote, Enquête, Quizz, Actualités, Galerie d'images...

Cette nouvelle version permet de se connecter à Silverpeas grâce à son compte Facebook ou LinkedIn. Cette intégration permet également à l'utilisateur de publier son statut s'il le souhaite sur ces deux réseaux sociaux.

Je ne vais énumérer ici toutes les nouveautés de Silverpeas 5.10, pour cela, je vous laisse le soin de consulter nos sites : 

www.silverpeas.com

www.silverpeas.org

Merci pour votre présence au Alpes JUG

Je tenais à remercier toutes personnes qui sont venues assister à la session "GWT : under the hood" au Alpes JUG le 31 mai 2012.

La salle était pleine :-)  GWT est donc un sujet qui intéresse.

Comme vous avez pu vous en rendre compte le sujet est vaste. Et malgré mes efforts pour être le plus synthétique possible, nous avons terminé la session à 22h passée...
Merci encore d'avoir résisté aussi tard.

Enfin, merci à l'équipe du Alpes JUG pour avoir mit sur pied cet évènement. Et particulièrement à Emmanuel Hugonnet, dont la motivation m'a poussé à faire le maximum pour que cette session ait lieu cette année (parallèlement à mes calendriers pro et perso chargés).

Pour ceux qui n'aurait pas pu venir, ou qui souhaiterait retrouver des informations, voici les slides de la session :

GWT : under the hood

View more presentations from svuillet.

Conférence au Alpes JUG

Le 31 mai j'animerais une conférence sur GWT au Alpes JUG. C'est une occasion pour moi de rester en contact avec le communauté Java et de partagé mes connaissances sur GWT.

Cette conférence se déroulera en deux temps :

- GWT core, optimisations et performances

- Développements GWT

Mon objectif est de présenter GWT pour ce qu'il est, en gardant intacte la vision de Bruce Johnson et Joel Webber.

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.

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.

Changement de travail

Après six années de bons et loyaux services pour la société Hinnoya, j'ai décidé d'aller relever de nouveaux défis technologiques au sein de la société Silverpeas.
Voici quelques informations sur Silverpeas :

Silverpeas développe une solution de portail collaboratif. Cette solution est Open source sous licence Gnu Affero GPL V3. Le portail Silverpeas est entièrement développé avec la technologie Java.

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.

Sweet home 3D

J'ai découvert récemment un petit logiciel assez bluffant, nommé "Sweet home 3D". Ce logiciel de conception de plan 2D et 3D est totalement écrit en Java et est publié sous la licence GNU.
Pour utiliser ce logiciel nulle besoin d'avoir des connaissances pointues en DAO/CAO, il est très facile de prise en main et est très productif.
Avec  "Sweet home 3D", il est possible de :

• dessiner les pièces
• dessiner les murs des pièces par dessus l’image d’un plan existant
• créer et éditer les côtes dans le plan
• glisser-déposer ses meubles dans le plan à partir d’un catalogue organisé par catégories
• importer ses propres modèles 3D dans le catalogue
• exporter les objets de la vue en 3D au format OBJ
• imprimer, exporter au format PDF, SVG

Ce qui est très agréable avec ce logiciel, c'est l'on visualise les modifications du plan en temps réel dans la vue en 3D, soit en vue aérienne, soit du point de vue d’un visiteur virtuel.

En conclusion, "Sweet home 3D" est à connaissance le seul logiciel libre aussi facile d'utilisation et aussi bien fini de sa catégorie. Bien sûr, il manque encore quelques fonctionnalités telle que la gestion des étages. Mais ce n'empêche en rien de l'utiliser et de concevoir des logements très réalistes.

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).

GWT s'ouvre et s'intègre

J'avais précédemment parlé de l'industrialisation de GWT, la semaine dernière a vu naitre la version 1.3 du plugin Eclipse de GWT. Cette nouvelles version du plugin est importante car elle permet l'utilisation des projets Dynamic Web d'Eclipse. Ce qui signifie une plus grande souplesse dans l'organisation des développements et la promesse d'une meilleures intégration avec Maven.
Les développements GWT vont donc se fondre dans les processus de développements JEE, ce qui devrait favoriser son adoption au sein de la communauté Java.

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.