Vous êtes ici : > Accueil > Documentation > Tutoriels > AJAX

 

Tutoriel AJAX

AJAX est une nouvelle technologie qui permet de faire énormément de choses, notamment dans le cadre du Web 2.0. C'est la définition que la plupart des prestataires qui le placent sur un piédestal vous donneront. L'objet de ce tutoriel est, tout d'abord, de tordre le cou à des idées reçues et, enfin, de dégager les points essentiels relatifs à son utilisation.

Introduction

Définition

AJAX signifie Asynchronous JavaScript + XML (XML et JavaScript Asynchrone) et propose d’utiliser les technologies web les plus répandues (XML, DOM, CSS et Javascript) dans le but de créer des interfaces utilisateurs plus réactives et ergonomiques.

Cette définition me plaît assez, mais force est de constater que beaucoup de développeurs oublient la seconde partie de celle-ci. En effet, aujourd'hui, utiliser AJAX signifie pour la majeure partie des développeurs, je prends une librairie Javascript, je la mets dans mon site et je ne me pose même pas la question de savoir s'il n'est pas possible de faire autrement.

Ce tutoriel AJAX n'a donc pas pour but de vous expliquer comment faire du AJAX (notion abstraite car générale). Il a pour vocation de limiter la mauvaise utilisation ou l'utilisation contre productive d'AJAX. En effet, en tant que développeur, je n'ai, d'expérience, jamais eu la nécessité de l'utiliser. Pas par simple rejet de cette pseudo-technologie, mais simplement que les choix qui s'imposaient comme évidents n'allaient pas dans ce sens.

Conséquences

Comme nous l'avons vu précédemment, AJAX utilise Javascript. Or, vous devez garder à l'esprit que son utilisation ne doit pas vous dispenser d'une solution alternative. Cela induit plusieurs inconvénients :

  • AJAX coûte deux fois plus cher en développement : solution AJAX et solution alternative.
  • AJAX coûte deux fois plus cher en maintenance. A supposer qu'entretenir du Javascript soit aussi simple que pour du HTML, ce qui n'est pas évident...

De plus, force est de constater que ceux qui utilisent AJAX, ne sont pas forcément des experts du DOM, ni de fins programmeurs. Ils utilisent souvent des codes sources qu'ils ne sont pas capables d'entretenir, ni d'adapter. Ceci pose un énorme problème quand à la pérennité des pages ainsi produites.

De ce fait, utiliser AJAX doit être une exception, un cas particulier pour lequel il n'était pas possible de faire autrement. C'est ce que je me propose de vous expliquer dans ce modeste tutoriel.

L'une des grandes utilisations d'AJAX est la navigation d'une page à une autre sans recharger la totalité de la page. Pour ce faire, seul un fichier XML contenant les informations désirées est chargé. Les arguments avancés sont alors :

  • Gain de bande passante : On réduit fortement le trafic car on ne charge que ce qui change.
  • Meilleure utilisabilité : Pas de clignotement au chargement, rapidité et fluidité des chargements.

Malheureusement, la plupart du temps, ces arguments sont faux.

De faux avantages, de vrais inconvénients !

En effet, cette utilisation d'AJAX présente de terribles inconvénients :

Les boutons suivant et précédent sont inopérants
Quoi de plus frustrant que le fait de ne pas pouvoir retourner à la page précédente ? Et quel est le gain en bande passante si, pour retourner à celle-ci, je dois recharger le fichier XML ?
Pas de marque page ou favoris
Votre site a fait son effet, le visiteur, ravi, souhaite mettre dans ses marques pages votre tutoriel sur Ajax. Deux mois plus tard, il revient sur votre site et se rend compte avec stupéfaction que c'est la page d'accueil qui s'affiche... Il est donc condamné à parcourir votre site à la recherche du fameux tutoriel. Multiplié par le nombre d'utilisateurs ainsi bernés, le trafic n'est pas vraiment allégé... Sans compter que les personnes souhaitant faire un lien vers ce tutoriel seront vite agacées de devoir chercher la bonne URL. Certains abandonneront, c'est sûr...
Les statistiques faussées
En effet, le journal des accès de votre site ne sera pas très lisible. L'accès à une page pouvant être un accès à un fichier XML ou à un fichier HTML. Ainsi, un doublon systématique en perspective.
Le référencement en péril
Les Google Toolbar, Yahoo Toolbar et consorts ont une fonction qui ne vous a surement pas échappée. Récupérer les comportements des utilisateurs ayant bien voulu jouer le jeu. Il y a fort à parier que celles-ci jouent un rôle prépondérant dans les résultats fournis par ces moteurs. Or, pour ces systèmes, vos visiteurs s'arrêtent tous à la page d'accueil ! On peut dès lors imaginer l'impact sur le référencement...

Si l'on résume, les gains en bande passante sont minimes voir annulés par les conséquences des inconvénients cités plus haut. Et enfin, l'utilisabilité, loin d'être améliorée est entravée par la disparition d'éléments clés de la navigation.

Et si la réponse était dans les standards ?

On connait et reconnait de plus en plus l'utilité des standards. La popularité du XHTML, que je mesure pleinement grâce aux visites sur ce tutoriel, va croissante. Mais il existe un standard plus méconnu peut-être parcqu'ancien mais dont les possibilités sont plus étendues qu'on ne le pense. Il s'agit du protocole HTTP.

Faîtes l'expérience ! La plupart des sites dynamiques ne l'exploitent pas au maximum. Allez sur un site réputé dynamique, cliquez sur un lien du menu et attendez le chargement complet de la page. Cliquez à nouveau et vous vous rendrez compte que le document est de nouveau chargé. Pourtant la probabilité qu'il ai changé dans un si court laps de temps est infime !

Le protocole HTTP, exploité au maximum, peut s'avérer extrêmement productif. Par exemple, pour ce site (mise à part sur les pages d'accueil, de contact et d'administration) vous n'auriez téléchargé ce document qu'une seule fois (à condition que comme 90% des utilisateurs, votre cache soit activé). Mais il existe mieux encore ! En effet, vous pouvez, de plus, spécifier aux proxys qu'il peuvent stocker vos pages dans leur cache partagé. Ainsi, pour un grand nombre d'accès potentiels, la page ne sera chargée qu'une seule fois !

Les gains en bande passante sont alors considérables et l'utilisabilité est renforcée car l'information est complétée par une entête HTTP correctement renseignée. Par exemple, sur Elitwork, 27.7% des codes de réponse HTTP envoyés sont des codes 304 qui signifient ce document n'a pas été modifié depuis votre dernière visite. On peut donc en conclure que cette petite manipulation a induit une baisse du trafic généré par la consultation de pages HTML de presque un tiers. Je vous renvoi donc à un excellent article sur la gestion des caches en PHP (oops, erreur 404, dommage pour cet article qui semble s'être envolé !).

AJAX et les formulaires

J'ai un ami, qui se reconnaîtra, excellent designer, mais pas programmeur pour deux sous... Un jour, il m'a témoigné sont envie de faire des formulaires en AJAX. Je ne savais pas que cela existait. C'est donc naturellement que je lui ai demandé de m'en dire plus à ce sujet. L'idée était de vérifier l'exactitude des données entrées grâce à une vérification auprès du serveur.

Encore un problème de la mauvaise connaissance des utilisateurs d'AJAX et des technologies sur lesquelles il est fondé. Ce problème peut être résolu grâce à notre cher couple DOM/Javascript sans avoir à entretenir tout une partie client/serveur inutile.

Là où le serveur est inutile

Il existe un moyen simple de vérifier les données entrées dans un formulaire sans avoir à faire appel à un script PHP. Cela ne remplace pas cette dernière vérification qui seule fait foi, mais permet d'éviter de nombreux rechargements pour indiquer qu'un contenu est inapproprié.

Il suffit d'ajouter un évènement à la soumission d'un formulaire et enfin, de vérifier le contenu des champs grâce à des expressions régulières.

Voici quelques exemples choisis :

Vérifier une adresse e-mail
if(/([0-9a-z_-.]+)@([0-9a-z_-.]+).([0-9a-z]+)/i.test(variable)) { alert('Le format de l\\'adresse courriel est corrompu.'); }
Vérifier qu'un champs textarea ne contient pas trop de caractères
if(variable.length>nb_carac_max) { alert('trop de caractères dans le champ textarea.'); }
Vérifier une URL
Par sa syntaxe :
if(/(http|https|ftp):\\/\\/([0-9a-z_-%\\]+)/i.test(variable)) { alert('Le format de l\\'URL est corrompu.'); }
Par son existence :
var request = new XMLHttpRequest();
request.onload = null;
request.open(HEAD, mon_adresse, false);
request.send(null);
if(!/2([0-9]+{2})/.test(request.status) || request.status != 304) { alert('Cette adresse n\\'existe pas sur le web'); }

Il existe beaucoup d'autres types d'astuces, pour les maitriser, visitez cette page.

Là où le serveur peut-être utile

Une des applications phares de l'AJAX sur les formulaires est la suggestion de mots-clés à la volée comme sur Google. Faire ce type d'application sans serveur serait impossible, à moins qu'un standard permette sa gestion par le navigateur, ce qui n'est malheureusement pas encore en vigueur.

Ajax et le E-Commerce

Afin de ne pas mettre en péril le processus d'achat, il peut être judicieux d'utiliser Ajax. Bien-sûr, puisque c'est une surcouche, cela aura un coût supplémentaire (si ce n'est pas le cas, veillez à ce que votre prestataire ne vous fournisse pas une version inexploitable sans Javascript).

Typiquement, c'est la mise d'un article au panier ou la gestion des quantités au sein de ce dernier qui peuvent être faits sans recharger de page. Attention à l'erreur répandue qui est de faire le catalogue en Ajax (et ainsi empêcher son indexation par Google, ce qui équivaut à tuer le site dans l'oeuf).

Les applications AJAX

Il existe aussi un engouement pour les applications AJAX... Comment ne pas s'extasier devant ces portails comme Netvibes,Yahoo Pipes etc... Rappelons que ces applications full Ajax sont réalisées par des équipes de développeurs spécialistes, bien renseignés et qui plus est, que sans Ajax, ces derniers n'auraient pu voir le jour. Il coûtent, par conséquent, très cher à maintenir.

De plus, leur fonctionnalités sont limitées, elles ne peuvent pas accèder au disque dur, par exemple. C'est pourquoi, une application de bureau banale s'avèrera, dans bien des cas, moins onéreuse, plus stable et plus évolutive. Vous pouvez, cependant, grâce à des langages tels que XUL (et XULRunner) créer des interfaces utilisateurs aussi facilement qu'une page web, mais tout en ayant accès à tous les privilèges d'une application desktop.

Je pense que l'avenir d'un site Internet n'est pas de devenir une application. L'application, c'est le navigateur ! On est dans un esprit client/serveur et il se trouve que le logiciel client est un navigateur. C'est pourquoi la page web ne doit pas s'immiscer dans un rôle qui ne lui est pas prescrit !

C'est la standardisation qui doit prendre le pas. AJAX permet de faire des choses qu'on ne pouvait pas faire avant. Soit ! Profitons-en ! Mais n'oublions pas que le W3C et les navigateurs ont pour rôle de nous simplifier la vie via la standardisation et leur support.

Pour l'exemple de l'auto-complétion d'un champs, on pourrait tout à fait imaginer quelque chose de ce genre :
<label for="ville">Ville</label>
<input id="ville" name="pville" autocomplete="autocomplete.php" />
Et un appel de ce type serait effectué à chaque changement du champs :
HTTP1.1 GET autotcomplete.php?value=(texte-saisi)

Aujourd'hui, qu'est-ce qui nous empêche de faire savoir au W3C qu'une solution telle que celle-ci nous parait primordiale ? Même si les navigateurs ne la supporteraient pas tout de suite, rien ne nous empêche de créer une classe qui le gère pour les navigateurs qui se seraient reposés sur leurs lauriers.

Un autre exemple, je me bat pour que les formulaires du prochain (X)HTML aient un attribut type. De cette façon, le navigateur chargerai automatiquement le plugin nécessaire pour éditer le champs en XHTML, BBCode, Wiki etc... Encore une fois, il suffit de le vouloir, techniquement, c'est faisable sans peine !

Les effets visuels

Voilà une application d'AJAX que je trouve sympathique bien que ça ne soit pas nouveau et qu'on pourrait appeler ça du Javascript, tout simplement. L'utilisation de classes qui permettent de faire des effets est intéressante et mérite, je pense, que l'on s'y attarde. Attention, toutefois, à ne pas utiliser des classes trop lourdes pour n'utiliser qu'une partie infime de leurs possibilités. Privilégiez les classes qui nécessitent le moins d'ajout au niveau du HTML. Un fichier Javascript externalisé peut accéder aux éléments d'une page sans forcément ajouter des attributs à ces derniers (voir : element.addEventListener()).

Le livre qui va bien

Vous avez aimé la vision d'Ajax de ce tutoriel ? Alors je vous conseille, si l'envie vous dit d'aller plus loin, de lire le bouquin Bien développer pour le Web 2.0 de Christophe Porteneuve et préfacé par Tristan Nitot, le président de Mozilla Europe.

Malgré le fait qu'il devient vite orienté Prototype (une des nombreuses librairies Ajax), il a le mérite d'introduire la notion de Javascript non-obstrusif ainsi que les rudiments de support des incompatibilités d'Internet Explorer, le navigateur du passé. A noter : des exemples compatibles avec les standards et des mémos sur les technologies annexes à Ajax.

Enfin, j'ai beaucoup aimé le contrôle de saisie générique par reconnaissance automatique du contenu des champs avec l'utilisation de l'attribut id (même si class eût été un meilleur choix)(ajout du 23/04/2009 : j'ai tellement bien aimé que je l'ai réécrite pour mes propres besoins, vous pouvez y jeter un oeil).

A propos

Ce tutoriel est une vision personnelle de l'utilisation d'AJAX qui n'engage que moi. A vous de vous y retrouver ou non. Je suis disponible par mail pour pousser le débat un peu plus loin ou simplement pour répondre à vos questions. En cas d'erreur, merci de me contacter. N'hésitez pas à lire mes autres tutoriels.

Bonne visite ! Nicolas FROIDURE.