Je passerai sur la présentation de l'objet XmlHttpRequest, il existe de nombreuses documentations sur Internet qui vous permettront de commencer à écrire des scripts utilisant cet objet. Cependant, en effectuant une utilisation plutôt intensive de cet objet, j'ai pu remarquer que ces documentations restaient toujours muettes sur de nombreux aspects problématiques.
Un script de test utilisant cet objet consiste souvent à envoyer une simple requête vers une URL et à recevoir la réponse à cette requête dans une fonction callback fixée par l'utilisateur. Rien de plus simple me direz-vous ? En apparence en effet.
Il existe pourtant deux points qui rendent l'utilisation de cet objet non triviale dans une vraie page web dynamique :
- il n'existe aucun moyen de vérifier que la connexion avec le serveur a bien été établie ;
- il n'existe aucun moyen de spécifier des callbacks indépendantes pour chaque requête.
Le premier point est très grave. Lorsque vous effectuez une requête HTTP vers un serveur distant, il n'existe aucune raison que ce serveur soit disponible. Bien sûr, c'est peu probable, car le serveur appelé est souvent le même que celui de la page web, il est donc disponible puisque la page web vient de s'afficher. Voilà une affirmation bien fausse. Ce n'est pas parce que vous venez de charger une page web que le serveur ne vient pas de tomber quelques secondes plus tard, de plus, rien ne garantit que l'application web que vous développez n'est pas destinée à fonctionner plusieurs heures sans jamais recharger la page principale (ce qui était mon cas), laissant ainsi largement le temps au serveur de tomber pour surcharge ou maintenance.
Le second point est moins grave, mais ennuyeux. Rares sont les applications web qui font toujours les mêmes requêtes. Il y a bien sûr ceux qui ont pensé à élaborer un protocole de communication assez simple afin d'avoir des fonctions de communications génériques. Cela permet de toujours utiliser la même fonction callback pour gérer les communications. Cependant, il est des cas où on ne contrôle pas ce que le serveur retourne (c'était mon cas), dans ce cas il est souvent nécessaire de mettre en place des fonctions callback différentes selon les différents types de réponse que l'on peut recevoir. La seule solution correcte dans ce cas est de créer autant d'objet XMLHttpRequest que de types de communication. Voilà qui n'est pas très pratique pour le développeur.
Selon moi, l'objet XMLHttpRequest marque un tournant dans la vie des développeurs d'applications web qui ne sont enfin plus dépendants du chargement des pages web pour récupérer des données depuis un serveur distant. Cependant, il existe encore des petites anomalies dans sa conception qui me font dire que son utilisation n'est pas encore à la portée de tout le monde, en tout cas pas pour réaliser des applications de qualité.
Pour continuer dans la veine du précédent billet, il est clair que le futur sera aux évolutions des langages de balisage (XUL, extension du HTML, XHTML 2, etc.) afin de redonner plus de responsabilités au navigateur et de revenir à plus de simplicité dans le développement d'applications web permettant ainsi de les fiabiliser plus facilement.
1 De Batmat -
+1 sur la conclusion... Même s'il permet des choses agréables par rapport à ce qui existait, même avec XHR, le développement Web est loin d'être la panacée.
Je le découvre de plus en plus, participant au développement d'applications web. Je me demande dans quelle mesure XUL et ses frères ou soeurs ne pourraient pas nous aider.
En effet, c'est un sacré bordel pour faire le moindre composant un peu plus évolué qu'un comboBox... Quant à parler de la mise en page d'un formulaire...
2 De SToto98 -
Je ne suis pas tout à fait d'accord avec ta première remarque (il n'existe aucun moyen de vérifier que la connexion avec le serveur a bien été établie). L'objet XMLHttpRequest possède deux attributs .readyState et .status qui te permettent respectivement de connaitre l'état actuel de la transaction avec le serveur (code numérique, 4 signifie que la transaction est terminée) et le code de retour du serveur (200 si ok, 404 si pas trouvé etc.). Que te faut il de plus ? ;-) Concernant le callback il te suffit de créer une fonction contenant la déclaration de l'objet XMLHttpRequest avec, en paramètre la fonction à appeler lorsque la transaction est réussie.
3 De Vincent -
En ce qui concerne le readyState, mes essais montrent que celui-ci atteint le niveau 4 que le serveur ait été contacté ou non (tests effectués sur Internet Explorer).
Cependant, lorsque le serveur est introuvable, ce sont les readyState 2 et 3 qui ne sont pas atteints. Ce qui donne 1, 2, 3, 4 pour une connexion réussie et 1, 4 pour un serveur introuvable. Je ne trouve pas cela vraiment intuitif.
Quant au status, il permet seulement de récupérer le code retour renvoyé par le serveur dans le cadre du protocole HTTP, cette valeur n'est pas du tout utilisable à partir du moment où la connexion n'a pas pu être établie.
Enfin pour les fonctions callback, ta solution est bonne, mais cela aurait été plus simple que l'objet fasse lui-même cette séparation et que ce ne soit pas au programmeur de trouver des solutions à ce problème.
Dans les deux points que j'énonce, je ne dis pas qu'il n'existe pas de solutions. Je dis juste que les solutions ne sont pas forcément évidentes et le fait qu'elles ne soient abordées dans aucun des tutoriels disponibles tend à me faire penser que peu de programmeurs les utiliseront, réduisant ainsi la qualité de leurs applications web.
4 De SToto98 -
Tu as raison en disant que l'ensemble n'est pas évident et qu'il n'est pas simple à prendre en main par les novices. De mon point de vue le système actuel, bien que perfectible, est assez souple pour me permettre de gérer l'ensemble de la transaction vers le serveur, malgrès effectivement la nécéssité de créer une surcouche à la fonction XMLHttpRequest pour gérer les différents aléas de cette transaction. Je crain qu'une méthode tout intégrée ne permettrai pas autant de souplesse (ou bien serait trop différente d'un navigateur à l'autre ce qui serait au final tout aussi pénible).
5 De Classics -
J'ai pas compris comment se servir de ça de façon efficace. Pourquoi ne pas passer par le navigateur.
6 De cweben -
A noter : readyState n'a pas le même type sous IE et sous firefox. (Numérique sous IE et alphabétique sous firefox) sinon, ca ne marche pas !