Marwan KHELIF » RIA

GWT 2.0 : les nouvelles fonctionnalités

mkhelif — Thu, 14 Jan 2010 12:05:54 +0000

La version 2.0 de GWT (Google Web Toolkit) est sortie (j’ai un peu de retard à cause du boulot ) et avec elle de nombreuses améliorations, principalement pour améliorer le développement des applications. Cette nouvelle version est accompagnée d’un outil d’analyse des performances des sites : Speed Tracer, qui donne des pistes d’amélioration de l’application.

Development Mode

Dans les versions précédentes de GWT, pour tester une application en cours de développement, il y avait le Hosted Mode. C’est une application que l’on lançait depuis son IDE, qui démarrait un serveur Tomcat et qui permettait de tester “rapidement” sont application Web.

En GWT 2.0 le Hosted Mode est remplacé par le In-Browser Development Mode. On installe un plugin (le GWT Developer Plugin) dans son navigateur pour lui permettre de communiquer avec la JVM. Cela permet de bénéficier des différents plugins de son navigateur (Firebug, …) tout en permettant de modifier le code Java en live en rafraichissant la page Web.

UI Binder

Un des problèmes majeurs de GWT dans ses versions précédentes est la gestion de l’interface graphique depuis le code Java. La manipulation des Widgets (composants graphiques dans GWT) depuis le code Java pour leurs appliquer des styles CSS ou gérer des événements finit par donner du code difficile à maintenir.

GWT 2.0 apporte une solution plutôt élégante avec l’UI Binder, ça permet de lier un template XML à une classe Java. Au passage, les fichiers CSS et JavaScripts (librairies externes) référençaient depuis le template sont compressées par le compilateur GWT afin d’en réduire la taille finale.

Ainsi, on sépare l’interface graphique (dans les template .ui.xml) et la logique de l’application dans le code Java.

Code Splitting

Voilà une fonctionnalité attendue par beaucoup de développeurs GWT. Lorsque l’on développe une application GWT, on se rend vite compte que le fichier JavaScript généré prend vite du poids. Cette fonctionnalité découpe l’application en plusieurs fichiers JavaScript qui seront chargés uniquement lorsque c’est nécessaire en rajoutant quelques lignes de codes.

Layout par contraintes

Beaucoup d’applications Web qui se basent sur JavaScript utilisent des widgets qui sont positionnées dans la page grâce à des calculs qui peuvent ralentir l’affichage de l’application.

À l’inverse, GWT 2.0 génère le rendu final en utilisant le CSS de la page, celui-ci est généré à la compilation et non plus pendant l’affichage de la page ce qui réduit considérablement le temps de chargement.

ClientBundle

Je présentais dans mon billet : Guide d’optimisation de vos applications Web une méthode pour réduire le temps de chargement d’une page en utilisant des images sprites.

GWT est capable depuis la version 1.4 de faire tout cela automatiquement grâce aux ImageBundle. Toutes les images référencées sur disque étaient réunies en une seule est GWT utilisé la technique des sprites pour afficher les images convenablement. Avec GWT 1.5/1.6, un projet de l’incubateur permettait de faire la même chose avec à peu près n’importe quels fichiers.

GWT 2.0 introduit cette notion avec les ClientBundle. Par exemple, vous pouvez références tous vos fichiers CSS, GWT va alors les regrouper en un seul fichier, le minimiser et le rendre disponible pour être mis en cache. GWT gère aussi l’internationalisation ainsi vous pouvez gérer vos ClientBundle pour chaque locale.

Speed Tracer

Cette nouvelle version sort avec une extension pour Google Chrome : Speed Tracer. Cette extension analyse l’exécution de l’application Web en cours. Plutôt que de longues explications, voilà la vidéo de présentation de Speed Tracer.

Présentation de Speed Tracer

Story of Your Compile

SOYC fournit de nombreux détails sur la compilation de chaque partie de l’application GWT : la taille, les dépendances, temps de compilation… Cela permet d’orienter ses efforts pour diviser le code grâce Code Splitting

Traces dans IE 6

Internet Explorer ne fournit pas les traces lorsqu’une exception JavaScript est levée, ce qui peut être très embêtant lors d’une phase de debug sur ce navigateur…

Avec GWT 2.0 vous obtenez maintenant la trace obfusquée (ou non en fonction de la compilation choisie) JavaScript qui peut être convertie en trace Java avec nom de classe et numéro de ligne.

Conclusion

Ce billet ne présente que les améliorations les plus importantes, mais il y à de très nombreuses évolutions : optimisation du compilateur, évaluation directe des réponses RPC (réduction du temps de déserialisation), propriété de deffered binding conditionnelles, …

GWT devient de plus en plus un framework “productif” : la plupart des problèmes qu’un développeur rencontre lors du développement d’une application Web qui utilise JavaScript, sont résolus très simplement.

Pensez-vous que cette version 2.0 de GWT va permettre au framework de gagner des parts de marché face à ses concurrents comme Flex?

Pour suivre votre lecture

Première utilisation du plugin Eclipse GWT

mkhelif — Fri, 10 Apr 2009 15:30:35 +0000

Suite à mon premier billet qui présentait Google Web Toolkit, je vais maintenant vous présenter la nouvelle version de GWT et comment créer un premier projet en utilisant le plugin Eclipse.

Mise en place de l’environnement de développement

Pour commencer à développer une application GWT et/ou GAE (Google App Engine), il faut télécharger la dernière version de Eclipse.

Une fois Eclipse installé et démarré, il faut installer le plugin GWT/GAE de Google. Pour cela allez dans le menu « Help / Software updates…« . Allez dans l’onglet « Available Software » et ajouter un nouveau site ( »Add site… ») et entrez l’URL : http://dl.google.com/eclipse/plugin/3.4.

Sélectionnez alors les éléments Plugin et SDKs, puis cliquez sur « Install« . Une fois l’installation terminée, vous devez redémarrer Eclipse. Là une nouvelle barre d’outils est apparue :

Le premier bouton sert à créer une nouvelle application Web GWT/GAE, le second à compiler une projet GWT et le troisième à déployer une application GAE dans le cloud Google.

Voilà votre environnement de développement est prêt à être utiliser.

Création de mon premier projet

Pour créer un nouveau projet cliquez sur le bouton . Cela va démarrer l’assistant de création de projet :

Les principaux champs à renseigner sont le nom du projet : GWTDemo, et le package racine de l’application : fr.mkhelif.gwt.demo. Pour l’exemple je n’ai sélectionné que GWT, je ferais un autre billet sur GAE.

Structure du projet

Une fois le projet créé, voilà la structure que l’on obtient :

On voit donc un nouveau dossier war, c’est celui-ci qui représente l’archive WAR qui sera exportée/déployée. Lors de la compilation du projet, les fichiers seront créés dans un sous-dossier de celui-là. Le répertoire lib du WEB-INF contient la librairie nécessaire au fonctionnement des service GWT-RPC sur le serveur.

On peut voir que le dossier public du package par défaut à disparu. Maintenant, toutes les ressources (images, css, …) doivent être placées dans le répertoire war à l’instar d’une application Web classique.

Notre nouveau projet contient par défaut deux fichiers : GWTDemo.html et GWTDemo.css. Le fichier HTML sert à charger l’application GWT et le fichier css représente le style de l’application.

Au niveau du répertoire de sources src, on retrouve les packages client et server, et le fichier GWTDemo.gwt.xml. Au niveau de ce fichier, il n’y a pas de changements notables.

Le nouveau projet contient un exemple de service RPC : GreetingService. Voilà le code de l’interface du service :

package fr.mkhelif.gwt.demo.client;
 
import com.google.gwt.user.client.rpc.RemoteService;
import com.google.gwt.user.client.rpc.RemoteServiceRelativePath;
 
/**
 * The client side stub for the RPC service.
 */
@RemoteServiceRelativePath("greet")
public interface GreetingService extends RemoteService {
    String greetServer(String name);
}

On remarque que l’interface étend toujours RemoteService, par contre une nouvelle annotation est présente : @RemoveServiceRelativePath( »greet »). Cette annotation permet de s’affranchir au niveau du code client d’enregistrer l’URL de la servlet du service :

1	((ServiceDefTarget) service).setServiceEntryPoint (GWT.getModuleBaseURL () + "greet");

Par contre il n’y a aucune différence au niveau de son implémentation et de son clone asynchrone.

Compilation du projet

Voilà le projet est créé, il faut maintenant le compiler en cliquant sur le bouton . Le wizard suivant apparait :

Il suffit de sélectionner le projet GWT, le niveau de log du compilateur et le style de sortie du JavaScript compilé. Sélectionnez ensuite les points d’entrées de votre application GWT, dans notre exemple il n’y en a qu’un.

On peut remarquer que grâce au plugin on peut spécifier des arguments de compilation. Le paramètre localWorkers permet de définir le nombre de workers utilisés pour compiler les permutations JavaScript. D’autres options sont disponibles mais ne concerne que les dossiers de compilation : workDir, war et extra.

Ayant un dual-core, je demande au compilateur d’utiliser 2 workers pour compiler. Le gain de temps est d’environ 30% : 28 secondes sans l’option et 19 secondes avec.

Utilisation de l’application

Une fois l’application GWT compilée, il faut la tester grâce au hosted mode. Il n’y a pas de grande différence au niveau du hosted mode, sauf que maintenant il est possible de modifier le serveur utilisé par GWT pour démarrer l’application.

On remarque un nouveau bouton Restart Server dans la fenêtre du hosted mode. Ce bouton permet de redémarrer le serveur, et donc de redéployer le WAR, sans avoir à relancer le hosted mode.

Conclusion

C’est un très beau coup de pub qu’à fait Google en nous servant en même temps le support de Java par Google App Engine, la version 1.6 de GWT et un plugin Eclipse pour gérer très facilement le tout. Cela va donner un coup de boost aux développeurs qui étaient encore hésitant sur la fiabilité de GWT.

Pour suivre votre lecture

Google : GWT version 1.6 et consorts

mkhelif — Wed, 08 Apr 2009 08:55:12 +0000

Ça y est, la version 1.6 officielle de GWT est enfin disponible après deux releases candidates (RC). Les nouveautés annoncées sont bien présentes. Parmi les nouveautés les plus importantes :

Une refonte de l’architecture d’une application GWT pour qu’elle corresponde à celle d’un WAR. Cette nouvelle architecture est plus intuitive pour développer une application complète (testée avec le plugin Eclipse Cypal Studio).
Une parallélisation du compilateur permet sur une machine multi-coeurs de diminuer sensiblement la durée de compilation. Maintenant, la compilation peut aussi être distribuée entre plusieurs machines.
Une nouvelle approche de la gestion de événements par Handler. Pour avoir testé cette nouvelle implémentation, on se rapproche beaucoup plus de la gestion des événements Swing.

En marge de GWT, Google App Engine, la plateforme de déploiement des applications Web de Google, accepte désormais les applications Java dans un environnement Java 6. Cet environnement comprend les API suivantes : Java Data Objects (JDO), Java Persistence API (JPA) et JavaMail API.

Par ailleurs, Google a aussi développé un plugin Eclipse pour les développeurs GWT et Google App Engine. Ce plugin contient :

Un assistant de création d’applications Web spécifique pour GWT ou Google App Engine.
Un assistant de déploiement de votre application dans le cloud de Google.
Une coloration syntaxique de votre code JSNI (JavaScript Native Interface). Très utile, surtout lorsqu’on à pris l’habitude de coder avec une coloration de commentaire…

Divers autres fonctionnalités sont disponibles avec ce plugin, mais je ne les ai pas encore testé.

Source : Introducing GWT 1.6 and friends.

Pour suivre votre lecture

GWT 1.6 : quoi de neuf ?

mkhelif — Thu, 11 Dec 2008 10:44:04 +0000

Ça y est la roadmap pour la version 1.6 de GWT a été publiée sur le blog officiel de GWT. Aucune date précise quand à la sortie de cette version, mais elle est annoncée pour le premier trimestre 2009.

Voilà les nouvelles fonctionnalités pour cette version :

Nouvelle structure de déploiement : l’objectif étant de permettre un déploiement plus simple des WARs sur un serveur d’applications. Il s’agit surtout d’une restructuration dont voici la spécification.
Jetty sera utilisé à la place de Tomcat (j’en parlais d’en un billet précédent). Une architecture plus modulable du hosted mode permettra de changer le serveur utilisé.
Uniformisation des événements : les listeners actuels seront dépréciés et les nouveaux seront uniformisés pour tous les widgets.
Intégration du DatePicker et du LazyPanel depuis l’incubateur GWT. Le DatePicker est comme son nom l’indique un widget permettant de sélectionner des dates (démo du DatePicker). Le LazyPanel permet de charger un composant uniquement lorsqu’on en a besoin (appel à la méthode setVisible (true)), ça permet de gagner du temps lors de l’initialisation de l’application.
Optimisation des String : les StringBuilder seront optimisés pour chaque navigateurs grâce au deferred binding (optimisation à la compilation).
Optimisation du compilateur GWT : réduction du temps de compilation.

Et celles qui sont prévues pour la suite :

Découpage du code JavaScript généré en plusieurs fichiers. Le développeur pourra spécifier des points de césures qui permettront au compilateur de découper le code généré en plusieurs fichiers. Cela permettra évidemment d’éviter au client de télécharger toute l’application GWT en un seul fichier. Ceci lié au LazyPanel, les applications GWT devraient gagner en rapidité de chargement.
Analyse du code compilé, appelée Story Of Your Compile (SOYC) : rapport permettant aux développeurs de savoir quelle classe génère le plus de code JavaScript.
Sélection du navigateur à utiliser pour le hosted mode.
Ui Binder : création des composants par déclaration, permet de séparer le layouting des composants (géré dans un fichier XML) de leur lien avec le modèle (géré dans le code Java).
Client Bundle : généralisation du deferred binding (utilisé actuellement dans les Image Bundle) aux autres ressources statiques (css : CSSRessource, texte : TextRessource, image : ImageRessource).
Optimisation du protocole RPC.

EDIT: La version 1.6 de GWT est sortie.

Pour suivre votre lecture

GWT : le futur hosted mode

mkhelif — Tue, 09 Dec 2008 09:42:05 +0000

Architecture : Out Of Process Hosted Mode (OOPHM)

La future version 2.0 de GWT nous annonce une grande amélioration du hosted mode. Pour rappel le hosted mode permet aux développeurs d’application GWT de pouvoir débugger leur code dans un navigateur embarqué sans avoir à passer par la compilation du Java en JavaScript.

La version actuelle du hosted mode ne permet pas de sélectionner le navigateur à utiliser (par défaut : IE sur Windows, Mozilla sur Linux et WebKit sur Mac). Cette nouvelle mouture permettra donc, à l’aide de plugins, de s’intégrer dans « tous » les navigateurs.

Ces plugins communiqueront par TCP avec la JVM de GWT et comme maintenant le code JavaScript ne sera pas généré ce qui permettra de débugger le code Java.

Source : DNG Consulting (regardez la vidéo ça donne envie).

Pour suivre votre lecture

RIA : quel framework choisir?

mkhelif — Fri, 03 Oct 2008 16:00:53 +0000

En tant que développeur je m’intéresse de près ou de loin aux différents frameworks RIA qui font leur apparition. Entre GWT, Flex, JavaFX (uniquement en béta), Silverlight, etc…on est souvent perdu dans la jungle des frameworks…

Xebia vient de rendre les résultats du concours entre les différentes technologies. Les différents développeurs devaient créer un gestionnaire de playlists web avec les différentes fonctionnalités : tri par catégories, artistes, albums, …

Le vainqueur est Flex grâce à sa maturité (richesse des composants, simplicité, …).

Voici le lien des résultats : http://blog.xebia.fr/2008/10/03/ria-contest-flex-silverlight-gwt-echo3-javafx/

Pour suivre votre lecture

GWT : version 1.5 disponible

mkhelif — Tue, 02 Sep 2008 08:20:14 +0000

Ça y est la version 1.5 du framework GWT (Google Web Toolkit) est enfin disponible. Voici la liste des nouveautés :

Gestion (enfin?) de Java 5 : génériques, autoboxing, énumérations, boucle foreach, imports statiques…
Le compilateur GWT ignore désormais les annotations non reconnues (JPA en particulier) ce qui permet d’utiliser ses beans directement dans l’UI.
Support des classes StringBuilder, TreeMap, LinkedHashMap et autres classes standards.
Gestion des assertions en activant le flag -ea.

Voici un lien vers toutes les nouveautés de la version 1.5 de GWT.

Pour suivre votre lecture

GWT : Créer un service RPC

mkhelif — Mon, 07 Jul 2008 16:05:59 +0000

Le framework GWT permet depuis le client JavaScript de faire des appels RPC (Remote Procedure Call ou appels de procédures distantes) au serveur GWT.

L’objectif est de permettre au JavaScript client d’exécuter des méthodes sur le serveur et d’en récupérer le résultat. Tout cela de façon totalement asynchrone (Ajax). Les échanges entre le client et le serveur sont faites de façon asynchrone car la plupart des navigateurs n’accordent qu’un seul Thread pour exécuter le JavaScript.

Infrastructure RPC

Pour permettre à JavaScript de faire des appels RPC il faut écrire le service côté serveur et la vue qu’en a le client. Le code d’un service RPC est séparé en deux packages : fr.mkhelif.gwt.client et fr.mkhelif.gwt.server.

Dans ce tutoriel nous allons créer un service Hello qui va tout simplement dire bonjour.

Package client

Le package client doit contenir les interfaces décrivant les méthodes du service.

/**
 * @author Marwan KHELIF
 */
public interface HelloService extends RemoteService {
	public String sayHello (String name);
} // HelloService

Voilà le code du service côté client qui sera utilisé pour effectuer des appels RPC en JavaScript.

On crée alors une interface qui sera utilisé par GWT pour effectuer les appels asynchrone. Cette interface est identique à celle que l’on vient d’écrire sauf que toutes les méthodes doivent retourner void et posséder un dernier argument en plus.

/**
 * @author Marwan KHELIF
 */
public interface HelloServiceAsync {
	public void sayHello (String name, AsyncCallback callback);
} // HelloServiceAsync

La classe AsyncCallBack contient deux méthodes qui permettent de gérer le résultat de l’appel :

public void onSuccess (Object result)
public void onFailure (Throwable ex)

Package server

Le package server (peut être nommé différemment) contient le code des services définis dans le package client.

Voilà donc notre implémentation du service Hello :

/**
 * @author Marwan KHELIF
 */
public class HelloServiceImpl extends RemoteServiceServlet implements HelloService {
	public String sayHello (String name) {
		return "Hello " + name + "!";
	} // sayHello ()
} // HelloService

Voilà notre service est prêt à fonctionner, il faut maintenant le rendre disponible aux clients. Pour cela il faut modifier le fichier de l’application GWT : MyApplication.gwt.xml

>
	
	 name="com.google.gwt.user.User" />
 
	
	 path="/hello" class="fr.mkhelif.gwt.server.HelloServiceImpl" />
>

Voilà notre service RPC est prêt à l’emploi.

Échange de données

Afin d’échanger des données entre le client (JavaScript) et le serveur (Java) il faut sérialiser les données pour qu’elles puissent transiter par le protocole HTTP. La sérialisation fournie avec GWT est différente de celle de Java.

Un type d’objet peut être utilisé en paramètre ou en retour d’une méthode de Service si c’est :

un type primitif : int, char, byte, double, boolean…
un objet de type : String, Date ou un wrapper de type primitif (Double, Long, Integer, Float, Boolean, …).
un tableau d’objets sérialisables.
une classe utilisateur qui implémente com.google.gwt.user.client.rpc.IsSerialisable ou java.io.Serialisable.

Dans notre exemple nous n’utilisons que le type String, il n’y a donc aucun problème de sérialisation.

Appel d’un service GWT

Une fois notre service crée, il faut effectuer des appels a sa méthode sayHello. Pour cela il faut demander à GWT de nous donner une référence vers ce service puis on appelle la méthode.

Instanciation du service

Pour instancier le service il suffit d’appeler :

1	HelloServiceAsync service = (HelloServiceAsync) GWT.create (HelloService.class);

Le cast de HelloService vers HelloServiceAsync est toujours sûr car l’objet Proxy créé implémente l’interface asynchrone.

Association du service à l’URL

Une fois notre service instancié il faut le lier avec le point d’entrée du service sur le serveur : /hello. Pour cela on effectue l’appel suivant :

((ServiceDefTarget) service).setServiceEntryPoint (GWT.getModuleBaseURL () + "/hello");

Voilà le service est mappé avec le serveur, on peut effectuer l’appel à la méthode.

Appel d’une méthode de service

Pour appeler la méthode du service :

service.sayHello ("Marwan KHELIF", new AsyncCallBack () {
	public void onFailure (Throwable caught) {
		// Traitement en cas d'erreur
	} // onFailure ()
 
	public void onSuccess (Object result) {
		// Traitement en cas de succès
		Window.alert ((String) result);
	} // onFailure ()
});

Voilà la méthode a été appelée sur le service RPC.

Conclusion

Les services RPC est l’un des points les plus importants du framework GWT. Ils permettent d’effectuer très simplement des appels au serveur en JavaScript et ainsi mettre à jour l’interface graphique grâce aux données.

Pour suivre votre lecture

GWT : Introduction au framework

mkhelif — Thu, 03 Jul 2008 14:48:03 +0000

Je travaille actuellement sur un plugin pour le logiciel NeoLoad permettant d’enregistrer des requêtes RPC effectuer par le framework GWT (Google Web Toolkit). Je vais donc en profiter pour présenter ce framework.

Qu’est ce que GWT?

Google Web Toolkit est un framework qui permet de créer un RIA (Rich Internet Application) sans avoir à écrire des centaines de lignes de JavaScript. GWT est un compilateur qui génére à partir de code source Java des fichiers JavaScript, XML et HTML.

Pour rendre dynamique le site vous pouvez ajouter une couche client-serveur RPC (Remote Protocol Call) entre le JavaScript côté client et le Java côté serveur. Cela permet de faire transiter par HTTP des objets Java entre le client et le serveur et des objets JSON entre le serveur et le client.

Afin de simplifier les étapes de tests et de débug, GWT fourni une JRE permettant d’exécuter l’application en local : Hosted Mode. Ceci évite la compilation de l’application et le déploiement sur le serveur.

GWT a donc pour but principal de simplifier et d’unifier le développement d’application Web : le développeur crée les classes Java nécessaire à l’application et GWT s’occupe du reste.

Le compilateur GWT

Dans cet objectif le compilateur GWT génère du code Javascript compatible pour la plupart des navigateurs : Firefox (version 1 à 3), IE (version 6 et 7), Safari (version 2) et Opéra (version 9).

Le code Java écrit par le développeur doit être compatible Java 1.4 minimum. GWT simule le comportement d’une JRE pour générer le Javascript, mais seulement certaines classes de l’API sont supportées : classes supportées par GWT.

Démarrage de l’application GWT

Chargement des paramètres du navigateur

Afin d’avoir une application qui fonctionne peu importe les paramètres de l’utilisateur (langue, version du navigateur, …) GWT va générer à la compilation un fichier JavaScript par type de navigateur supporté et par langue de l’application.

Lorsqu’un utilisateur accède à la page d’acceuil de l’application GWT va charger le fichier JavaScript correspondant à la configuration de l’utilisateur.

Page HTML

La page HTML d’entrée dans l’application ne contient qu’une frame vide qui va charger le JavaScript adéquat selon la configuration de l’utilisateur.

L’application démarre en plusieurs étapes :

Chargement de la page HTML par le navigateur.
Chargement et exécution du JavaScript .nocache.js.
Le code JavaScript récupère la configuration du navigateur et récupère à partir d’une table (générée par GWT) le nom du fichier HTML à utiliser.
Le JavaScript crée alors une frame cachée qui est insérée à la fin du body de la page.
Lorsque le fichier HTML est chargée l’application est démarée.

Fichiers générés par le compilateur

Fichier JavaScript .nocache.js

Ce fichier permet de chargée une version de l’application compatible avec le navigateur du client.

Ce fichier contient une table avec en clé la configuration du client et en valeur l’URL du fichier HTML à charger. Par exemple ce fichier contiendra une entrée avec ‘Firefox en français’, ‘IE en anglais’, ‘Opera en allemand’, …

Chaque navigateur ayant une interprétation du JavaScript différent, cela permet de tirer parti de toutes les spécificités du navigateur.

Ce fichier nocache doit être re-téléchargé par le navigateur à chaque chargement de la page car il est recréé lorsque l’on recompile l’application. Cependant le nom ne change pas.

Fichier HTML .cache.html

Ces fichiers HTML (il y en à un par navigateur et par langue) contient uniquement le JavaScript compressé de l’application. Le fichier JavaScript n’est pas envoyé directement car certains navigateur ne supporte pas le JavaScript compressé. Il est donc inclus dans du HTML afin d’éviter les problèmes de compatibilité.

Chaque fichier HTML a pour nom la signature MD5 de son contenu afin d’éviter que plusieurs fichiers HTML aient le même nom. Ainsi si vous modifiez le code de votre application, les fichiers n’auront pas le même nom.

Ces fichiers étant différents à chaque compilation, ils peuvent être mis en cache par le navigateur. D’où leurs noms cache.html.

Fichier .gwt.rpc

Si votre application utilise des appels RPC vers le serveur et que les requêtes utilisent les objets Java que vous avez créé, ces objets doivent être sérialisés pour pouvoir transiter par le protocole HTTP.

Ces fichiers définissent quels objets doivent être sérialisés et leur politique de sérialisation.

Conclusion

Voilà une première introduction au framework GWT. Ce framework est très prometteur car il permet de s’abstraire de tous les problèmes que l’on rencontre pendant le développement d’une application AJAX.