XmlHttpRequest : comment ça marche ?
Par Bruno le dimanche 20 mars 2005, 00:08 - Informatique - Lien permanent
Mais d'où ça vient ?
C'est Microsoft qui est à l'initiative de cet techno pour IE 5, elle a ensuite été ajoutée aux spécifications Load and Save du W3C. Aujourd'hui compatible avec la plupart des navigateurs récents, l'utilisation du XmlHttpRequest va prendre de l'ampleur !
Quel est l'enjeu ?
C'est la sensation de rapidité, mais attention, la vitesse de transfert des données entre le serveur et le client n'est pas plus élevée, par contre nous développons différement : on peut travailler en tache de fond.
Exemple du flag dans Gmail (Pour ceux qui ne suivent pas, connectez vous à Gmail avec le login demoxmlhttprequest et mot de passe xml2005 et essayer de cliquer sur les étoiles à gauches des messages). Je vois trois façons de "flaguer un message" :
- Le clique sur l'étoile envoie un formulaire au serveur qui renvoie une page au client avec le message flagué (évidement très long...)
- Le clique sur l'étoile envoie un formulaire au serveur dans une iframe cachée. Le résultat n'est pas visible dans une autre page tant que l'update n'est pas terminé. L'étoile change de couleur grâce au DOM (d'où l'impression de rapidité).
- Enfin, avec le XmlHttpRequest, on peut aborder le problème différement : au chargement de l'application Gmail, l'ensemble des données sont chargées sur le client sous la forme d'un "arbre" xml (ce n'est ni un flux, ni un fichier...) . Toute action entraine une modification de cet arbre local et est donc immédiate. La synchronisation entre l'arbre local et les données serveur peuvent se faire en tâche de fond. Il n'y a jamais aucun rafraichissement de l'application. L'étoile change de couleur grâce au DOM (d'où l'impression de rapidité).
Comment ca marche ?
La connexion est différente sous Internet Explorer et FireFox. Le plus de l'utilisation du XmlHttpRequest est sans aucun doute la possibilité d'utiliser une communication asynchrone entre le client et le serveur.
Les différentes valeurs de la variable readyState :
- 0 : non initialisé
- 1 : les données ont commencé à être transférées
- 2 : les données sont transférées
- 3 : les données sont partiellement exploitables sur le client
- 4 : les données sont totalement exploitables
Exemple (dans une autre page):
Des utilisations du XmlHttpRequest :
- Gmail de Google : Si vous voulez une adresse, demandez en une dans les commentaires ou par mail !
- Un exemple de Apple avec ses explications.
- Google suggest.
- L'application URBA de la société LUCCA utilise cette techno dans ses listes déroulantes (dans la popup de réservation)
Commentaires
Quand je lis (ou plutôt quand j'essaye de lire ) ce genre d'article, j'ai l'impression de ne pas parler la même langue. Visiblement, et le commentaire de Pololand le prouve, y'en a qui ont l'air de bien suivre! Moi je suis complètement largué... C'est grave docteur??
C'est vraiment un grand phénomène de mode qui vient sur le tard, surtout quand on sait depuis quand cette techonologie est disponible. C'est bien de voir tout le monde s'y mettre, ça offre de belle possibilité :)
C'est vrai qu'elle est disponible depuis un petit bout de temps, mais je crois que de voir Google s'investir et (investir) à 200% dans cette techno aide les sociétés à y croire...
Article sur Google Maps : bruno.catteau.free.fr/ind...
Avec responseText, ça marche bien pour un habitué du HTML, et encore, avec quelques soins ...
après tout, c'est une commande JAVASCRIPT qui ramène du code selon la question initiale...
Mais avec responseXML, je ne comprends pas trop ou cela va réagir .... du XML dans du HTML ? ou du XML dans du JAVASCRIPT ? Beurk, je vais vomir ...
Du XML dans du Javascript, que tu peux analyser en javascript directement grâce au DOM
req.responseXML.documentElement te permet d'attaquer le flux XML
puis par exemple
listeComm = req.responseXML.documentElement.getElementsByTagName('items');
et ensuite tu peux boucler dessus.
Xquery et Xpath ne marche pas encore il me semble, par contre, tu peux transformer ton texte grâce au XSLT. Google Maps est basé sur ça (entre autre...) maps.google.com/mapfiles/... c'est le script de Google Maps qui s'occupe de la transfomation pour Internet Explorer et FireFox.
Tu peux regarder tout particulièrement ce projet d’interpréteur xslt en javascript avec gestion du xpath…
sourceforge.net/projects/...
lemoineo passer par du code javascript dans la réponseText suppose deux chose une que tu maitrise le contenu de la réponse. c'est donc toit qui écrit la page. deux il te faut t'assurer que le javascript en question sera tout terrain. et enfin tu n'est pas à l'abris d'une ursupation d'identité du serveur qui alors poura s'envoyer un JS qui vérole tout.
passer par du XML sépare la réponse du ser du language qui va le traité.
ta réponse peut dès lors être ouverte par d'autres outils.
tu peux par exemple instancier un xmlhttprequest dans un document word et récupéré tes valeurs alors que tu avait initialement créé ton "service" pour le web.
A+JYT
Merci pour cette impression très juste !
C'est vrai que c'est la discussion d'aujourd'hui : renvoie t on les données en txt ou en xml.
1. J'ai été déçu par les temps de traitement du xml par le javascript de Internet Explorer. Je vais essayer de faire un billet sur mon test. Les tableaux sont gérés très rapidement.
2. Dans les dernières version de Gmail, voilà la nature du retour :
D(["ds",0,0,0,0,0,0,0]);
D(["ct",[["boulot",0],["perso",0]]]);
D(["ts",0,50,803,0,"Tous les messages","","1052f4c9bda",1808,,""]);
Le serveur renvoie donc toujours la meme fonction avec comme premier paramètre le contexte d'utilisation, puis l'ensemble des paramètres. Effectivement, il faut que la fonction D soit blindée pour qu'elle s'en sorte dans chacun des contextes.
3. Et en argument contradictoire, l'étude de Google Maps qui prône le xml/xls "maison" (cf, commentaire 6)
En tout cas, en est tous là : "quelle est la techno la plus performante ? "
chapeau :)
tout le monde doit lire ca pour comprendre!!
Ce post m'a paru très pertinant à mon gout, c'est vraiment une réussite, bonne continuation.