Comprendre les mécanismes d'AJAX

Lorsque l'on soumet un formulaire, le navigateur récupère les valeurs des éléments du formulaire soumis possédant un attribut name puis transmet ces couples nom / valeur à la page définie par l'attribut action via une requête HTTP soit en les ajoutant à l'URL soit dans le corps de la requête selon la valeur de l'attribut method (« GET » dans le premier cas, « POST » dans le second).
PHP reçoit ces paramètres dans les tableaux $_GET ou $_POST. Les valeurs sont alors nécessairement de type chaîne. Il ne peut pas en être autrement pour deux raisons :

• Comme nous l'avons déjà évoqué, le protocole ne connait pas les types.
• Il est nécessaire de passer par une couche supplémentaire, le HTML, pour transmettre les données, or HTML n'accepte pas les variables et ne reconnait donc pas les types non plus.

PHP peut alors construire une nouvelle page en prenant ces informations en compte puis renvoyer un nouveau document HTML au navigateur. Le navigateur recharge alors la page pour afficher le nouveau contenu.
Vous noterez toutefois que les champs de formulaires peuvent être remplis en JavaScript. Il est donc possible de transmettre des représentations textuelles des variables JavaScript à PHP (voire de les réintégrer dans la nouvelle page). Mais il s'agira tout de même d'un contexte JavaScript différent.

Comme pour les formulaires, il est possible de transmettre des données depuis un lien. Cependant, nous sommes ici limités à la méthode GET, c'est-à-dire à les faire passer par l'URL. Ces paramètres sont à inclure dans l'URL après un point d'interrogation (« ? ») sous forme de couples nom / valeur séparés par le caractère « & » :

www.developpez.com?toto=tata&auteur=bovino

Là encore, nous sommes limités à des données textuelles, mais nous pouvons ajouter avec JavaScript des valeurs à transmettre :

<a href="www.developpez.com" id="test">Lien</a>
<script type="text/javascript">
    var variable = 'bovino';
    var parametres = '?toto=tata&auteur=' + variable;
    document.getElementById('test').href += parametres;
</script>

Vous constaterez que la couche HTML est ici aussi nécessaire pour communiquer avec le serveur.

L'objet location de JavaScript comprend quatre méthodes permettant de faire une redirection. Il est donc possible d'utiliser ces méthodes pour transmettre des paramètres.

location.href = 'www.developpez.com?toto=tata&auteur=bovino';
location.assign('www.developpez.com?toto=tata&auteur=bovino');
location.replace('www.developpez.com?toto=tata&auteur=bovino');

Il faut noter qu'ici, c'est JavaScript qui appelle directement la requête HTTP, il n'y a plus d'intermédiaire HTML, en revanche, c'est le moteur HTML qui reçoit la réponse du serveur.

Le point commun de toutes ces méthodes est que l'on envoie des informations au serveur qui renvoie un document complet. Il y a donc nécessairement rechargement de la page. AJAX va nous permettre de modifier uniquement des portions de page lorsque le rechargement complet n'est pas nécessaire. Nous allons voir ce que cela change par rapport aux modèles précédents.

L'utilité essentielle d'AJAX est la capacité d'utiliser des informations présentes sur le serveur dans un script JavaScript sans avoir à recharger la page. Les exemples typiques d'utilisation sont nombreux, par exemple :

• Modifier une partie de la page sans avoir à la recharger entièrement comme c'était le cas dans les techniques présentées auparavant.
• Enregistrer à la volée des informations sur le serveur.
• Vérifier la validité et/ou la disponibilité (pseudos, mots de passe…) de champs de formulaires avant de soumettre ceux-ci (ATTENTION : cela n'exonère pas des vérifications côté serveur !)
• Proposer des suggestions lors du remplissage d'un champ de formulaire (autocomplétion).
• Etc.

En effet, dans les communications client / serveur sans utiliser AJAX, on parle de navigation, c'est-à-dire que le serveur doit renvoyer une page HTML complète au navigateur qui se charge ensuite de l'afficher. Le navigateur a besoin d'une page complète (et si possible valide) pour l'afficher correctement.
À l'inverse, dans le cas d'AJAX, nous souhaitons juste mettre à jour une partie de la page, y insérer une page HTML complète constituerait donc une erreur grave de conception et risquerait de provoquer des erreurs d'affichage.
Il est cependant possible de créer côté serveur un fragment HTML (par exemple le contenu HTML que l'on veut insérer et qui peut lui-même comporter des balises. Mais ce fragment ne sera pas interprété comme du HTML, mais comme du texte simple.

JavaScript ne pourra interpréter la réponse que comme du texte. Cependant, la méthode de création est identique à celle utilisée pour la création d'une page. En PHP, le résultat retourné par le serveur sera celui qui aura été affiché avec des instructions echo par exemple. Le script PHP devra donc organiser le résultat obtenu de façon a être facilement exploitable par JavaScript. Il existe différentes techniques pour cela :

• Renvoyer du texte simple, par exemple si vous avez juste un message à renvoyer.

echo 'Ce login est invalide';

• Un document XML.

• Un objet JSON (JavaScript Object Notation).

S'il est un langage de balises permettant de structurer parfaitement les données, XML génère en contrepartie des échanges conséquents de données souvent inadaptées et qui nécessitent d'être ensuite analysées (« parsées ») dès réception. Le format d'échange JSON est ainsi naturellement apparu ; il présente l'avantage d'organiser les données de façon comparable, mais beaucoup plus légère, en utilisant la syntaxe des objets JavaScript, et de les rendre directement utilisables :

{nom1: valeur1,
nom2: valeur2,
nom3: {
    sousnom1: sousvaleur1,
    sousnom2: sousvaleur2
}
}

On utilise des couples nom / valeur, chaque couple est séparé par une virgule (mais il ne faut pas de virgule après le dernier), les noms et les valeurs sont séparés par deux points (caractère « : »). Les valeurs peuvent elles-mêmes être des objets.

Le format JSON offre plusieurs avantages :
- Il est léger et facilement manipulable.
- Il est normalisé, cela signifie que n'importe quelle application supportant ce format peut accéder à son contenu sans avoir à ajouter quoi que ce soit.

En revanche, il présente aussi un inconvénient : s'agissant finalement d'une donnée typée, il ne pourra pas être envoyé en tant que tel, mais sous forme de texte, il faudra donc l'évaluer avec JavaScript avant de l'utiliser.

• Un système de pseudo XML en séparant les différents résultats avec des séparateurs prédéfinis.

$nom1 = $valeur1;
$nom2 = $valeur2;
$nom3 = $valeur3;
echo $nom1.'<>'.$valeur1.'<arg>'.$nom2.'<>'.$valeur2.'<arg>'.$nom3.'<>'.$valeur3;

Les avantages de ce type de format sont : - Il est relativement léger et facile à mettre en œuvre. - Il est directement exploitable en JavaScript et chaque élément facilement récupérable au moyen d'appels à la méthode split() de l'objet String.

Les inconvénients :
- Il n'est pas normalisé, il est donc nécessaire de bien documenter sa structure.
- Il devient vite lourd à gérer en cas de structure trop complexe (imbrications multiples par exemple).

Une requête AJAX se décompose en différentes étapes :

• Créer un objet XMLHttpRequest (voir un exemple dans la FAQ).
• Définir les actions à réaliser lors des différentes réponses du serveur (méthode onreadystatechange()).
• Récupérer les éventuels paramètres à envoyer.
• Ouvrir une connexion avec le serveur (méthode open()).
• Envoyer la requête au serveur (méthode send()).

Vous constaterez qu'avec AJAX, c'est JavaScript qui envoie et qui reçoit les données. Il s'agit d'une différence essentielle avec la navigation classique.
En effet, nous avons vu que c'est le moteur HTML qui insère le JavaScript dans le contexte du document et cela lorsqu'il rencontre une balise <script>. Donc, comme le moteur HTML n'intervient pas dans une requête AJAX, ce qui signifie que :

Bon d'accord, j'exagère un peu… Mais il faut bien comprendre que le code JavaScript contenu dans la réponse du serveur est, comme tout le reste, considéré comme du texte, il est donc nécessaire de l'évaluer (avec la méthode eval()) avant de pouvoir l'utiliser, tout comme les réponses au format JSON.

eval(XMLHttpRequest.responseText);

Il est cependant à noter que l'utilisation de eval() est plutôt déconseillée en règle générale.
Cette méthode oblige à appeler le moteur JavaScript, ce qui réduit considérablement les performances.
Cette méthode est aussi considérée comme peu sécurisée, car elle donne une importance exagérée au texte évalué.
Dans le cadre d'AJAX, on peut se dire (avec bon sens) qu'étant donné la Same Origin Policy (SOA : politique de même origine) inhérente à JavaScript et donc à AJAX, les risques sont minimes. C'est logiquement le cas si l'on considère que le développeur est compétent, ce qui n'est pas toujours le cas… mais qu'en est-il si la page appelée par votre requête fonctionne à la manière d'un proxy, qui est encore aujourd'hui la méthode la plus courante pour faire de l'AJAX inter domaine ? Avez-vous vraiment confiance dans les intermédiaires chez lesquels vous récupérez vos données ?
Il faut toutefois être conscient qu'il est impossible d'éviter l'utilisation de eval() pour interpréter du JavaScript récupéré par AJAX.
De ce fait, si vous avez à inclure du JavaScript dans un document via AJAX, demandez-vous au préalable si vous ne faites pas de fautes de conception et donc s'il n'y a pas un moyen plus académique de procéder.
D'après mon expérience, les cas où il est impossible de procéder différemment sont assez rares.

Une utilisation détournée de eval() serait de passer directement par le DOM, l'intérêt étant de rendre le script accessible dans le contexte global si vous l'évaluez par exemple dans le cadre d'une fonction anonyme de rappel type callback :

var lafonction = XMLHttpRequest.responseText;
var lescript = document.createElement('script');
lescript.type='text/javascript';
lescript.appendChild(document.createTextNode(lafonction));
document.getElementsByTagName('head')[0].appendChild(lescript);

Il est aussi important de comprendre à quoi correspondent les notions de requêtes synchrones ou asynchrones.
Le principe est relativement simple et bien compris, mais les implications sont plus difficiles à appréhender.

Lors d'une requête synchrone, la fonction qui la contient bloque son exécution tant que la réponse du serveur n'a pas été reçue. À titre de comparaison, c'est presque le même fonctionnement qu'avec une boîte d'alerte. Les implications sont que de ce fait, aucun code JavaScript ne peut être exécuté pendant ce temps, la page n'est plus interactive.

Lors d'une requête asynchrone au contraire, la requête est lancée, mais le code de la fonction continue à s'exécuter. C'est habituellement un intérêt majeur d'AJAX, en revanche, il est important de notifier au visiteur que l'action qu'il a déclenchée est en cours d'exécution, car rien n'est plus agaçant que de cliquer sur un contrôle devant effectuer une action et de ne rien voir arriver…
Une autre conséquence, au niveau du développeur, est de bien comprendre que pendant le cours de la requête, la fonction qui l'a créée continue son exécution et bien souvent termine son exécution avant que la réponse du serveur ne revienne. Or, quand une fonction termine son exécution, son contexte est détruit.
De ce fait, il est important de savoir que si vous avez besoin des résultats de la requête dans la fonction qui la crée, vous risquez d'être obligé de passer par une requête synchrone.
En général, on préfèrera envisager tous les traitements de retour dans la fonction appelée par la réussite de la requête (ce que l'on appelle habituellement le callback) via l'événement onreadystatechange en prenant bien soin de rendre disponibles les éléments du contexte requis.

L'aspect asynchrone ne représente que la valeur par défaut d'une requête AJAX, elle est cependant celle que je préconiserais.
Tout comme pour les évaluations de scripts, les cas où l'utilisation de requêtes synchrones est indispensable sont plutôt rares et je préfère tenter de privilégier les actions des utilisateurs au maximum.