[Retours d'expériences] XmlHttpRequest

Bonjour à tous !

voilà maintenant un bon moment que la technologie en vogue XmlHttpRequest fait parler d'elle. J'ai eu l'occasion de faire mes propres tests pour essayer, me familiariser... ou bout du compte ça m'a semblé assez puissant pour les bénéfices que ça peut apporter à une application en terme de prise en main et de temps de traitement des infos. D'un autre côté, ça complique pas mal de choses et on se retrouve vite avec beaucoup de fichiers pour au final faire pas grand chose de plus... sans parler du temps de développement...

J'aimerais savoir si certains d'entre vous ont adpoté cette technologie pour leurs développements de tous les jours, si certains ont réussi à dompter la bête assez pour y trouver un réel bénéfice sans trop augmenter le temps de développement?

J'aimerais donc des retours d'expérience, en bien ou en mal... vos sentiments sur l'avenir de ce nouveau joujou...

en bref, est ce qu'Ajax mérite qu'on s'y attarde et qu'on change sa façon de travailler pour l'utiliser plus ou moins génériquement dans des projets d'applications sur le web?

Merci pour vos (futures) réponses

SuD

Bonjour,

J'ai fait un petit essai sur la home page de mon site, pour proposer différentes images et fonds d'écrans.

Cela n'apportait pas grand chose pour cette application et je ne l'ai donc pas mis en oeuvre.

Le js fait moins de 7 ko (http://www.sutekidane.net, il faut le modifier si mes souvenirs sont bons pour fonctionner sur tous les navigateurs.

J'ai examiné la question pour une autre application (genre commerce électronique).

Comme cette application doit être facile à consulter dans des zones du globe où le "haut débit" est de l'ordre de 56 k, le calcul est vite fait : il faut faire le nécessaire avec un renouvellement classique des pages, sans Ajax et ses fichiers assez lourds (par rapport au poids de mes pages).

A vue de nez la procédure d'achat que je mets au point se fera en quelques pages dont le poids total (données communes et données particulières à chaque contenu) sera probablement bien inférieur aux js indispensables à Ajax.

Mais je ne dis pas que je n'utiliserai pas une solution comme celle que j'avais essayée, si je m'aperçois qu'elle apporte vraiment un surplus d'efficacité sans diminuer l'accessibilité.

Bonjour,
J'ai mis en place une solution en Ajax pour une recherche thematique d'un site marchand assez important. Ce "module" est disponible en permanence dans le "menu droit" du site.
Principe assez classique: au début un seul menu déroulant (ex :maison/Salle de bain/cuisine ...) en séléctionnant une catégorie on obtiend une deuxième (ex: cuisine ->electro/lave vaisselle/fours ...) , puis une troisième (si il y à ...)
Après essai ce menu était impossible à réaliser avec du js classique (par exemple, génération de tous les cas possibles) car le fichier généré était trops gros.
Au final, cela fonctionne très bien en ajax, et après quelques petites adaptation (utilisation de frame si pas de support d'ajax) c'est compatible avec la tous les navigateurs que j'ai testé (firefox, opéra, IE, safari, ie Mac !).
Sur le même site, j'ai également placé (à un endroit moins fréquenté du site) un champ type "google suggest", mais cela tiens plus du gadget qu'autre chose ...

Pour conclure (et répondre à Sud):
- cela a apporté un réel bénéfice sans trop augmenter le temps de développement

- Je compte le ré-utiliser mais pas génériquement: seulement quand c'est indispensable et que cela rajoute un "plus"

Ajax me fait un peu penser à Molière et M. Jourdain qui faisait de la prose sans le savoir. Je veux dire par là qu'on parle d'une pseudo nouvelle technologie qui ne fait que reprendre des techniques existantes.
Toutefois c'est selon moi, une nouvelle philosophie d'intégration de plusieurs technologies qui demande à murir. Donc à suivre...
Intuitivement je pense que les limites rencontrées par ajax du fait de la non utilisation de techniques type PHP/MySQL seront difficilement franchissables.
PS : Il y a un livre qui me semble t-il, pourrait constituer une bonne préparation à AJAX "des CSS au DHTML"
Modifié par charlynancy (24 Nov 2005 - 03:14)

AJAX c'est tout sauf dépendant de PHP/MySQL

a écrit :

Intuitivement je pense que les limites rencontrées par ajax du fait de la non utilisation de techniques type PHP/MySQL seront difficilement franchissables.

Gnié ?

On peut utiliser AJAX avec ou sans PHP/MySQL et inversement... Je ne vois pas ce que tu veux dire.
Modifié par Lanza (24 Nov 2005 - 09:18)

je m'ai mal expressé
Bien sur, Ajax n'interdit pas l'utilisation de PHP MySQL, je voulais dire que les possibilités d'AJAX peuvent faire croire qu'on peut se passer de PHP MySQL; ce qui est faux nous en convenons tous.
En fait, ce que je soulevais ce sont les possibilités théorique du XML à se passer d'une base de données...qui selon moi ne sont que théoriques... Ceci dit, il faut être le plus ouvert possible à toutes ces nouveautés et loin de moi l'idée de jouer les gourous des nouvelles technologies.

bonjour,

J'utilise Ajax à petite échelle, le gain en temps de dévellopement n'est pas evident, par contre il permet facilement à des utilisateurs non experts d'
ajouter des contenus en html "simplifié", sans qu'ils aillent massacrer le header et la mise en page du conteneur.
C'est pratique quand on ne veut pas se donner la peine de faire une usine pour administrer un petit site, par contre je ne pense pas que je m'appuyerai dessus à plus grande échelle.

charlynancy:
le xml ne se subsitue pas à une base de donnée (en pratique), par contre j'ai vu un système de cache de requetes sql (en xml) qui marche vachement bien.

Lapin : je me cite :

a écrit :
possibilités théorique du XML

pour te confirmer que nous sommes bien d'accord que

a écrit :
le xml ne se subsitue pas à une base de donnée

Je précise tout cela car on pourrait penser à la lecture de certains articles que les applications web vont être entierement écrite avec AJAX...
A contrario, cet article : ajax le retour des lessiviers vous permettra sans doute de prendre un certain recul
Modifié par charlynancy (27 Nov 2005 - 05:39)