Introduction

Aujourd’hui les technologies de base fournies par les navigateurs web, c’est à dire afficher le contenu de documents, ont été poussées jusqu’aux limites.

Ajax (Asynchronous Javascript + XML), un nom récent donné par Jesse James Garrett d’Adaptive Path , bien que techno assez ancienne mais longtemps gardée secrète (anciennement connue sous le nom de dynamic HTML ou remote scripting), a été propulsé au devant de la scène l’année dernière par Google avec ses célèbres Google Suggest et Google Maps.

Construire une interface de client riche est un poil plus compliqué que créer de simples pages web. Riche définit le modèle d’interaction du client. Un modèle d’interaction est celui qui supporte un grand nombre de possibilités en entrées en répondant de manière intuitive et de façon très dynamique.

Pour vous faire une idée, prenez une application de votre choix (autre qu’une application web) et comptez le nombre d’interactions proposées. Comparez le avec une application Web classique (non riche). L’application desktop (par exemple un tableur) va vous offrir des fonctionnalités telles que : le curseur peut changer de forme, les boutons changent d’aspect quand on passe la souris dessus, le texte sélectionné change de couleur, on peut editer les données in situ, etc, etc…

Le navigateur web quant à lui va offrir des fonctionnalités telles que gérer la navigation du client (boutons retour et avance), liste d’historiques, onglets pour voir plusieurs sites en même temps.

C’est là qu’Ajax intervient, pour aider le développeur à augmenter le nombre d’interactions dans son application web, et se rapprocher de la richesse d’une application desktop.

Les 4 principes d’Ajax :

1) Un navigateur héberge une application, et pas du contenu : dans une application web classique, le navigateur n’est autre qu’un simple terminal. Chaque fois que l’utilisateur interagit avec un site, un nouveau document est envoyé vers le navigateur, avec un mélange de données et de présentation. Le navigateur supprime l’ancien document (page) pour le remplacer par le nouveau.

Avec une application Ajax, une partie de la logique serveur est transférée vers le client. Le document cette fois ci va rester dans le navigateur tout au long de la session. Comme ce document persiste, différents états peuvent être stockées désormais dans le navigateur.

2) Le serveur fournit de la donnée, et pas du contenu: comme on l’a dit précédemment, dans une application web classique le serveur fournit un mélange de données et de présentation (HTML). Dans le cas d’un shopping cart, tout ce dont nous avons besoin, c’est la valeur du prix, par exemple.

Une application Ajax enverrait une requête asynchrone au serveur, et en retour ne recevrait que la donnée du prix. Toute la présentation resterait inchangée du coté du navigateur.

3) L’interaction utilisateur avec l’application doit etre fluide et continue: Dans une application classique, prenons l’exemple de la soumission d’un formulaire : quand l’utilisateur fait un submit de la page, la page courante reste encore visible un moment. L’utilisateur est invité à attendre que la page entière soit rafraichie.

Reprenons l’exemple du shopping cart. Comme notre application Ajax envoie des requêtes asynchrones, l’utilisateur peut continuer de son coté à rajouter des éléments au panier. Si le code client est robuste, il va supporter ces charges très facilement, et l’utilisateur pourra continuer à faire ce qu’il lui plait sans avoir besoin d’attendre quoi que ce soit.

4) Ca représente du vrai codage et ca requière de la discipline : On fait une application Web depuis longtemps à base du langage Javascript. Pourtant Javascript a longtemps été sous estimé par les développeurs, qualifiés de plus “sérieux”.

Désormais, dans une application avec Ajax , le code délivré quand l’application se lance doit être exécuté jusqu’à sa fermeture : cela sans casser, sans ralentir, sans générer de fuites de mémoire. Pour atteindre cela, nous devons désormais appliquer les techniques de développement server side, pour écrire des applications performantes et maintenables.

Pourquoi DWR :

Le problème pour un développeur web qui crée des applications avec Ajax, est que cela peut rapidement s’avérer très difficle : un des principaux problèmes étant l’hétérogénéité des navigateurs (Firefox, IE, Opera), qui n’ont pas toujours le même comportement, et cela même en fonction des OS (Windows, Linux, Mac OS X).

DWR, hébergé sur java.net, est une librairie open-source qui aide les développeurs à créer des applications web incluant les technologies Ajax. Sa définition est “Easy Ajax for Java”. DWR permet d’avoir du code dans un navigateur qui fait appel à des fonctions Java du serveur, comme si elles étaient du coté client.

Le but de cette démo est de montrer comment créer une appli de chat multi utilisateurs, en une centaine de lignes de code. Comment integrer Ajax dans le client avec du Java sur le serveur.

L’application:

Le code HTML est très simple.

Nous reviendrons sur le Javascript un peu plus tard. Continuons par le code du serveur.

Nous avons 2 classes pour faire marcher le serveur. La première, Message, utilisée pour stocker la valeur du message. Cette classe contient un ID unique, qui sera l’heure en milli secondes:

Le constructeur fait des choses simples : il tronque le message a 256 car. et remplace certains caractères spéciaux.

Intéressons nous a la classe Chat, qui a pour but de garder les messages envoyés en mémoire.

Deux de ces methodes sont importantes pour le client sur le navigateur : addMessage(), pour envoyer la chaine de texte. Et getMessages(), qui sera accédé en polling de temps en temps pour récupérer les nouveaux messages.

Configurer DWR :

Maintenant on doit rendre ces 2 classes remote. Pour cela downloader DWR depuis le site dev.java.net . Deposer dwr.jar dans le répertoire WEB-INF/lib. Configurer la servlet DWR dans le fichier web.xml :

Maintenant on doit informer DWR que :

  • La classe Chat est safe et peut etre rendue remote pour le navigateur.
  • La classe Message est autorisée à devenir un paramètre.

Ce paramétrage se fait dans un fichier nommé dwr.xml, devant etre placé dans le répertoire WEB-INF a coté de web.xml :

Scripting coté client

Il nous reste à intégrer le Javascript coté client. DWR rend les choses simples et nous évite de coder les appels a XmlHttpRequest, faire de la manipulation DOM, ou récupérer les paramètres.

On inclue déjà les liens vers le Javascript :

Le script engine.js contient le coeur de DWR. Vous pouvez voir la documentation complète ici. Le script util.js contient des fonctions optionnelles, mais pouvant etre fort utiles. Enfin le script Chat.js est généré automatiquement et correspond a la version remote de Chat.java; son code ressemble à :

Chat.addMessage = function(callback, p0) { ... }
Chat.getMessages = function(callback) { ... }

Il faut juste savoir que pour ces versions remote des classes Java, le premier paramètre est toujours la fonction Callback appelée en réponse d’une requête XMLHttpRequest asynchrone.
Implémentons la fonction qui sera appelée quand l’utilisateur aura écrit son texte et appuiera sur le bouton ‘Send’ :

function sendMessage()
{
var text = DWRUtil.getValue("text");
DWRUtil.setValue("text", "");
Chat.addMessage(gotMessages, text);
}

La première ligne récupère la valeur du champs portant l’id ‘text’ (objet de formulaire de type Texte)

Ensuite nous effacons le champs texte avec DWRUtil.setValue(“text”,”").

Enfin nous appelons la fonction addMessage de l’objet Chat : la fonction callback  fait appel a la fonction gotMessages qui recupere la liste de tous les messages jusqu’à présent envoyés sur le serveur.

Code de la fonction gotMessages :

function gotMessages(messages)
{
var chatlog = "";
for (var data in messages)
{
chatlog = "


" + messages[data].text +
"


" + chatlog;
}
DWRUtil.setValue("chatlog", chatlog);
}

La methode Java Chat.addMessage() retourne un objet List d’objets Message . DWR convertit automatiquement cette collection en objets Javascript. On a juste à itérer sur le tableau de messages dans la méthode gotMessages() : on récupère le texte du message et on construit le HTML. Ensuite on pousse la chaine de caractéres construite vers un objet DIV grace a DWRUtil.setValue(…)

Et voila! On obtient ainsi un chat multi utilisateurs, certes basic, mais fonctionnel.

Conclusion

DWR rend donc la vie plus facile pour créer des applications web AJAX cross browser, avec Java sur le serveur.

Ressources :

Ajax in Action

Developing Ajax applications the Easy Way

Code de l’application