GWT : Google Web Toolkit

Le secret !

Tout d'abord, le framework GWT peut être récupéré à l'adresse suivante :
http://code.google.com
Ne vous préoccupez pas de quelle version télécharger, ni si elle sera compatible avec votre système d'exploitation, Google connaît déjà toutes ces informations, et vous propose directement la bonne version dont vous devez vous soucier.
Laissez-vous donc porter par ce doux parfum de développement...


Comment ils font tourner la roue chez GWT ?

Commençons à être plus sérieux, et parlons architecture & code.

En gros...

Vous pouvez donc retrouver ci-dessus l'architecture globale du framework :

Le fonctionnement général pour le développeur est donc celui-ci :
  1. Ecrire l'interface graphique, en utilisant les widgets fournis par GWT, et les émulations de librairies Java
  2. Ecrire les servlets si besoin
  3. Compiler le code avec le compilateur Java-To-Javascript
  4. Tester/exécuter l'application

L'interface graphique

Développer l'interface graphique d'une application GWT est la même chose que développer une application avec le framework Swing. La seule différence est que les widgets utilisés sont ceux fournis par Google, et qu'il sont créées dynamiquement par la suite pour du code HTML, et non des graphiques sous forme de pixels.
Cela permet donc de simplifier le travail du développeur, qui n'a pas à se préoccuper comment faire un bouton ou une liste en HTML.

GWT propose donc une multitude d'éléments graphiques que vous pourrez trouver sur cette page, ils ne seront pas énumérés ici car je ne souhaite pas que la page fasse 3Km de long, et que par la suite, vous n'ayez pas le courage de finir l'article...


De plus, à ces éléments graphiques, il est possible comme pour Swing de leur affecter des événements lorsqu'ils sont appelés. Pour cela, ils utilisent un modèle d'interface de type Listener similaire à Swing. Cette interface définit une ou plusieurs méthodes appelées lorsque le widget est activé.

Le compilateur (propriétaire)

http://java.dzone.com/news/understanding-gwt-compiler

L'idée de base de GWT est d'écrire notre application en Java, de la débuguer en Java, et de transformer ce Java an Javascript. Il faut donc un compilateur spécifique, que Google s'est amusé à faire.
D'un point de vue général, ce compilateur parse le code Java, puis créé un arbre syntaxique AST (Abstract Syntax Tree), s'occupe d'optimiser le code, le transforme en Javascript, et optimise le code Javascript encore une fois.

D'un point de vue plus précis, voilà comment ça se passe :

  1. Chargement du module ModuleDefLoader

    Ce module effectue un parcours récursif de l'arbre des modules créés par l'utilisateur (une encapsulation des fonctionnalités qu'il a écrites), et extrait les informations
  2. Préparation des permutations
    Cette phase consiste à compiler le code Java en des versions Javascript différentes en fonction des navigateurs : seules les classes utiles pour la plate-forme/navigateur sont utilisées. Par exemple, sous Firefox, seule l'implémentation du DOM pour Firefox est utilisée pour la compilation, il en est de même pour tous les autres navigateurs (Opera, IE et mê Safari), en fonction de l'internationalisation de l'application. Cette pratique permet de réduire la taille du code qui sera appelée.

    Le compilateur permute donc son fonctionnement en fonction des navigateurs, il y aura donc 4 versions de l'application.
  3. Génération des fichiers

    Tout d'abord, il faut savoir que Javascript est beaucoup plus permissif que le Java, car il en comporte pas un système de classe aussi bien défini. Il est donc plus simple d'implémenter du Java vers du Javascript. Ainsi, lors de la transformation d'une classe Java en Javascript, une classe Javascript est créée et son constructeur. Après, il est ajouté tous les champs et les méthodes polymorphes.La difficulté est d'arriver à retranscrire le langage Java correctement, car les spécifications de fonctionnement sont très exactes.

    Nous avons indiqué plus haut que plusieurs versions sont créées, pour répondre aux besoins des navigateurs. En plus des ces versions, un script de sélection est généré : ce fichier Javascript est exécuté sur le client, et permet de définir la version à utiliser.
  4. Optimisations du compilateur

    Au final, le compilateur effectue aussi une série d'optimisations :
    • il supprime les classes, les champs et les méthodes inutilisées
    • il finalise les méthodes et les champs
    • il réécrit le code non-polymorphique en appel statique
    • il infère les types les plus spécifiques pour éviter d'utiliser des types abstraits, et les méthodes
    • il élimine le code inutile ( non accessible, ou qui renvoie toujours les mêmes valeurs

    Le seul inconvénient rencontré avec ce compilateur concerne le support des librairies Java. En effet, elles ne sont pas toutes encore supportées en terme de compatibilité.

    Les émulations de librairies

    Comme indiqué dans l'explication du compilateur, toutes les librairies Java ne sont pas implémentées pour être utilisées dans GWT. En effet, transformer du Java en Javascript n'est pas toujours aussi facile tout de même.

    GWT propose donc une émulation de librairies JRE, mais qui n'émulent pas toutes les classes Java. Par exemple, elle supporte un certain nombre des classes des paquetages java.lang et java.util, mais pas la totalité.

    En plus de cette émulation, Google a mis en place un système de sérialisation des données propres à GWT afin d'améliorer le RPC.

    Le principe client/serveur selon Google

    Nous avons parlé plus haut de RPC, ou Remote Procedure Call, qui est protocole permettant de faire des appels de procédures sur un ordinateur distant à l'aide d'un serveur d'application.

    Ce mécanisme permet d'interagir avec le serveur de manière simplifiée en faisant transiter des objets Java, dans le cas de GWT. Utilisé correctement, le protocole RPC permet de déporter la parte graphique sur le poste client, le serveur n'a plus qu'à faire le traitement des données : on a alors un gain de performance, un gain de bande passante, une charge du serveur moins élevée, et une impression de fluidité pour les interactions de l'utilisateur.

    Dans le cas de GWT, la sérialisation des objets Java est utilisée. Mais attention : ce n'est pas la sérialisation offerte par Java, qui est utilisée, mais celle propre au framework GWT. Alors que la sérialisation Java est basée sur la réflexion, codée en binaire, et utilise les méthodes readObject et writeObject, GWT propose une sérialisation qui est effectuée au niveau du compilateur (ce qui implique donc que si ça compile pas, ça RPCera pas...), de manière complètement statique, car Javascript ne supporte pas le type de sérialisation Java. Ce n'est donc pas de la vraie sérialisation, comme on peut la connaître.

    Ce type de sérialisation est appliquée sur les paramètres des méthodes et leur retour, sachant que la majorité des types Java standards sont gérés : char, byte, short, int, long, boolean, float, double, String, Date, Integer...

    D'une manière globale, il faut donc que les champs ou objets utilisés soit GWT serializable : cela implique qu'ils doivent soit être implémentés par l'éumlation de librairies GWT, soit implémenter l'interface IsSerializable fourni avec le framework, ou dériver d'une classe mère qui l'implémente.

    JSNI

    Eh oui... Encore un mot barbare... Et qui n'est même pas sur le schéma au dessus !

    JSNI, ça veut dire JavaScript Native Interface. Ben oui, du Javascript. Car même si GWT vous enlève l'épine du pied en transformant du Java en Javascript, il peut être utile des fois d'insérer du vrai Javascript, comme par exemple si l'on souhaite insérer un autre framework orienté Javascript, comme Dojo. C'est pourquoi il est possible dans une application GWT d'encapsuler du vrai Javascript dans le code, même s'il devient moins portable (la force de GWT !). Inversement, il est possible d'appeler du code Java avec le Javascript, de la même manière que le ferait du JNI.

    Il est donc possible de relier de cette manière la couche client et la couche serveur, le Javascript étant côté client et pouvant appeler les méthodes Java du serveur, et toutes les conséquences que cela entraîne.

    Sur le principe, pour exploiter cette fonctionnalité, il faut utiliser les références de la fenêtre du navigateur ($wnd) ou du DOM ($doc). Lors de la compilation, ces références sont automatiquement initialisées aux objets voulus.

    Juste pour vous faire une idée, voici ce que cela donnerait pour fair un alert en Javascript :

    public static native void alert(String msg) {
        $wnd.alert(msg);
    }




    Et nous dans tout ça...

    Enfin, on va s'occuper un peu de vous pour de vrai, car on vous avait un peu délaissé... Ici, on va voir comment mettre en oeuvre GWT, mais on en parlera encore plus en détail dans la prochaine section !

    2 modes...

    Dans GWT, il faut savoir qu'on peut exécuter l'application Web que l'on a créée de 2 manières :

    • Mode Hosted : l'application est alors exécutée en tant que bytecode Java, dans un faux navigateur qui est en fait une JVM. Il est alors possible de tester/débuguer le code, en mettant des points d'arrêts... Ce n'est donc pas du code Javascript qui est exécuté, mais directement le code Java.

    • Mode Web : cela concerne l'application Web une fois qu'elle a été compilée, on peut donc y accéder avec un navigateur standard. Cette fois-ci, c'est le code Javascript qui est exécuté, on a donc l'application finale.

    Réaliser un projet GWT

    Ahhhhhhh quand même !!

    Pour cela, il est fourni dans le framework GWT 3 outils :

    • projectCreator : cet outil permet de générer le squelette d'une application GWT standard. De plus, il peut générer les fichiers nécessaires aux projets Eclipse et le script Ant de compilation du projet.
    • applicationCreator : cet outil permet de générer, en plus du squelette, une application GWT minimaliste.
    • junitCreator : cet outil permet de générer un ensemble de classes et de scripts, permettant le test de votre application en mode local et distant.

    Au final, il suffit de taper les lignes de commande suivantes pour avoir un projet GWT :

    projectCreator -eclipse XPose
    applicationCreator -eclipse XPose com.umlv.gwt.client.XPose
    On obtient alors ce qu'on appelle un module dans le jargon GWT, avec un certain nombre de fichiers qui ont été créés et une arborescence spécifique.

    Mettre quelques boutons, pour le fun

    Ben oui, là, on a juste le minimum, donc pour agrémenter, rajoutons par exemple un bouton. Le code à rajouter sera alors :

    Button b = new Button("Normal button", new ClickListener() {
        public void onClick(Widget sender) {
            Window.alert("HAHahahhahahahaha (rire sarcastique)!!");
        }
    });

    Ce code est juste là pour montrer la similitude avec le développement de l'interface graphique sous Swing. Comme la Javadoc de GWT est bien documentée concernant les widgets disponibles, et que je suis faignant, mais que je vous apprécie, voici donc le lien vers le détail, avec le code associé aux widgets :
    Widgets powaa !

    C'est encore plus utile si ça fait des choses sur le serveur (mise en place du RPC)

    Voici déjà une partie plus intéressante, la mise en place du protocole RPC dans une application GWT. En gros, le schéma qui montre comment l'implémenter :
    Vous n'y comprenez rien, c'est normal. Enfin non, mais on va vous expliquer quand même, ça sera plus simple. Sur le schéma, on peut voir les éléments suivants :

    • YourService : une interface synchrone du service, extension de RemoteService (côté client), qui est implémentée par YourServiceImpl
    • YourServiceAsync : une interface asynchrone du service, qui est liée à l'interface synchrone (côté client), et doit avoir les mêmes méthodes que la synchrone. L'exception réside dans le fait qu'elle possède un objet AsyncCallback en paramètre, et retourner void. De plus, la convention de nommage veut que son nom soit identique que l'interface synchrone, avec le suffixe Async
    • YourServiceImpl : une implémentation de l'interface, extension de RemoteServiceServlet (côté serveur)

    Passons aux étapes pour mettre en place tout cela :

    1. Ecrire les 2 interfaces : synchrone et asynchrone
    2. Implémenter le service du côté serveur : implémenter les interfaces, et hériter de RemoteServiceServlet
    3. Configurer le service dans le fichier de configuration du module
    4. Lancer un appel du client pour tester !

    La suite dans la prochaine section, avec la démo !