Cours présentation AJAX avec Prototype

Participez au vote ☆☆☆☆☆★★★★★

Cours présentation AJAX avec Prototype

...

AJAX est encore trop souvent mal compris par les débutants. Qu'il s'agisse de sa mise en œuvre, de ses capacités ou de sa nature même. Cet article va tenter de dégonfler les différentes baudruches concernant cette "technologie". Nous verrons aussi en quoi AJAX se différencie des différentes techniques d'inclusion de contenu.

Préambule

Cet article n'a pas pour objet de vous apprendre à utiliser AJAX, mais de vous faire comprendre ses mécanismes.

Pour ceux qui souhaitent en savoir plus, je vous invite à consulter :

En particulier, pour les débutants et en complément de cet article : Ajax : Vos premiers pas dans les nouvelles technologies et Web 2.0, allez plus loin avec AJAX et XMLHttpRequest.
La FAQ AJAX.

Avant toute chose, il est important de bien comprendre comment est architecturée une communication client / serveur. Il existe deux types de communication entre le client (habituellement, le navigateur) et le serveur, les communications dites "statiques", c'est-à-dire qui se contentent d'envoyer vers le client un flux de données présentes sur le serveur et les communications dites "dynamiques" qui effectuent un traitement sur le serveur pour renvoyer au client le résultat de ce traitement. Un schéma valant mieux que de longs discours, voici des représentations des architectures client / serveur statiques et dynamiques :

Schéma représentant le fonctionnement d'un site statique :

Relation client / serveur statique

Schéma représentant le fonctionnement d'un site dynamique :

Relation client / serveur dynamique

AJAX : késako ?

Ce qui fait généralement le plus peur quand on commence à aborder AJAX, c'est l'apparente complexité pour obtenir une instance XMLHttpRequest. XMLHttpRequest est la clé de voûte d'une requête AJAX, sans lequel il est impossible de faire quoi que ce soit. Historiquement, la technologie AJAX est apparue en 1999 avec IE5 ; à l'époque aucune norme AJAX du W3C n'existe et donc aucune notion d'objet XMLHttpRequest. Microsoft choisit alors de s'appuyer sur sa technologie ActiveX MSXML. Un an et demi plus tard Mozilla propose l'objet XMLHttpRequest, dont les noms des fonctions sont calqués sur celles de l'ActiveX de IE5 pour conserver un maximum de compatibilité entre les navigateurs. De facto XMLHttRequest devient une norme (Safari, Opera, Chrome l'adoptent) et c'est en 2006 que le W3C publie ses premières spécifications. L'objet XMLHttpRequest apparait ainsi dans IE7. Une seconde version des spécifications est finalement publiée en 2008. Toujours est-il que la complexité n'est qu'apparente et que l'implémentation se fait assez facilement.

Cependant, AJAX n'est rien d'autre qu'un acronyme ! Pour bien le comprendre, décomposons-le :

AJAX : Asynchronous JavaScript And XML, soit en français : JavaScript et XML asynchrones. Cependant, nous allons voir que les termes employés sont parfois là uniquement pour générer l'acronyme !

Asynchrone : il s'agit de la capacité de communiquer avec une ressource coté serveur sans figer le navigateur (c'est-à-dire que le reste de la page reste actif), il est à noter que bien que l'aspect asynchrone d'une requête Ajax en fait souvent un avantage non négligeable, cela ne reste qu'une option, il est tout à fait possible de créer des requêtes synchrones, qui bloqueront donc votre page tant que le serveur n'aura pas répondu.
JavaScript : et bien oui, AJAX n'est rien d'autre que l'utilisation de l'objet (ou ActiveX) XMLHttpRequest de JavaScript. Tout ce que vous aurez à savoir pour créer une requête Ajax efficace, ce seront les différentes propriétés de cet objet.
Et XML : si le XML se justifiait à l'époque des premières évocations d'AJAX (la mode était au XML et les formats alternatifs comme JSON n'existaient pas), il est aujourd'hui controversé. Toujours est-il que le retour d'une requête AJAX est supposé être soit du texte, soit du XML, on comprend donc bien que ce X est surtout là pour l'acronyme !

Mécanisme de création d'une page HTML

Avant de rentrer plus en détail dans le déroulement d'une requête AJAX, il est important d'avoir une idée claire du déroulement de création d'une page Web et en particulier de la communication client / serveur. Dans cet article, j'ai pris comme référence de langage serveur le PHP. Sachez que c'est un choix arbitraire et que tout ce qui suit est valable quel que soit le langage serveur utilisé !

Lorsqu'un internaute demande une page Web via son navigateur, il va chercher un fichier sur un serveur. Une connexion est donc ouverte vers le serveur pour pouvoir communiquer avec lui. Si le fichier en question est identifié comme du HTML (par son extension essentiellement), alors, il "comprend" que le résultat sera directement exploitable par le navigateur et renvoie donc le contenu du fichier au navigateur qui ferme la connexion. En revanche, s'il comprend que le contenu est du PHP (j'insiste, ou tout autre langage serveur), alors, il sait qu'il doit d'abord interpréter le code contenu dans le fichier pour pouvoir renvoyer au navigateurs du code HTML compréhensible par le navigateur, que l'on appelle du coup "généré". Bien entendu, quand je dis que le code généré sera compris par le navigateur, cela implique que le développeur a bien codé sa page ! Une fois le code interprété, le résultat est envoyé vers le navigateur qui l'affiche, sans savoir qu'il s'agit d'un document PHP, ce qui du reste ne servirait à rien car un navigateur ne sait pas évaluer du code PHP, puis ferme la connexion.

Interaction PHP / JavaScript

Les notions abordées ici se limitent aux cas des requêtes HTTP de type GET ou POST (les plus courantes), s'il existe des méthodes autorisant les connexions dites persistantes, elles dépassent largement le cadre de cet article.

JavaScript (dans le cadre d'une requête AJAX) est lui interprété sur le navigateur. La conséquence du fonctionnement décrit précédemment est que les interpréteurs PHP et JavaScript ne fonctionnent jamais en même temps !

En effet, lorsque le serveur interprète le PHP, le document HTML n'existe pas, il n'existera qu'une fois le contenu reçu et affiché sur le navigateur, donc une fois la connexion client / serveur fermée. A l'inverse, lorsque l'interpréteur JavaScript entre en action, c'est-à-dire dès que le navigateur aura rencontré une balise

... ... ...

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. A 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...