Discussion :

[kagura]

Bonjour,
Avant deux min, j avais l idée que AJAX est un language de programmation comme php
Mais maintenant j'ai lu un article qui m a fait changé l idée et je sais mnt que c'est pas un language de programmation. mais c'est quoi? une technologie qui regroupe xml et javascript. ben c est ce que j'ai compris.
Quelqu'un peut m eclaircir un peu? Je serai tres reconnaissante.
Merci d'avance.

[Swoög]

En fait, AJAX est un "module" de JavaScript qui permet de faire faire une requête HTTP via JavaScript (sous certaines conditions liées à la sécurité) afin de rapartrier des informations venant du serveur.

Le plus souvent, les informations sont retournées sous forme de document XML puisque le (pseudo-)module DOM intégré à JavaScript permet ensuite de les traiter plus facilement (d'où l'appellation Asynchronous Javascript And XML), mais on peut utiliser tout type de document (texte) pour le retour des information.

[tthierry]

>En fait, AJAX est un "module" de JavaScript qui permet de faire faire une requête HTTP via JavaScript

tu parle de l'objet xmlhttprequest là, c'est juste un composant (qui existe depuis plusieurs annés tout comme le dom et le css) qui participe à une méthode dev internet estampillé ajax, web2 ....

histoire de se la raconter je rajoute aussi qu'ajax permet d'amener la logique d'un client riche sur le web vu qu'on peut acéder aux infos du serveur sans avoir à recharger la page (xmlhttprequest), tout peu devenir asynchrone.

ça permert aussi de retravailler la page (dom+css via js), de générer des fuites mémoires (l'internaute peut rester des heures sur l'appli sans rien recharger...c'est un peut fait pour d'ailleur), de surcharger le serveur, de se marcher sur les pieds en fonction des requêtes simultanées qui sont lancées (modifier un item alors qu'un autre appel au serveur vient de le déplacer sans avoir pu encore afficher le résultat), de générer de nouvelles failles de sécurité, d'apprécier les différentes façons de voir des navigateurs, ....

...un nouveau jouet pour les dev internet en somme

[Swoög]

>En fait, AJAX est un "module" de JavaScript qui permet de faire faire une requête HTTP via JavaScript

tu parle de l'objet xmlhttprequest là, c'est juste un composant (qui existe depuis plusieurs annés tout comme le dom et le css) qui participe à une méthode dev internet estampillé ajax, web2 ....

oui, j'avais plus le nom exact du truc en tête

de générer des fuites mémoires (l'internaute peut rester des heures sur l'appli sans rien recharger...c'est un peut fait pour d'ailleur)

si c'est mal géré oui ^^

de surcharger le serveur

ah bon !? j'aurais plutôt dit l'inverse...

de se marcher sur les pieds en fonction des requêtes simultanées qui sont lancées (modifier un item alors qu'un autre appel au serveur vient de le déplacer sans avoir pu encore afficher le résultat), d'apprécier les différentes façons de voir des navigateurs

je vois pas en quoi c'est spécifique à AJAX...

de générer de nouvelles failles de sécurité....

!? encore une fois, si c'est bien fait je vois pas pourquoi ça serait le cas.

...un nouveau jouet pour les dev internet en somme

que nous ne sommes d'ailleurs pas obliger d'utiliser

[tthierry]

pour le "si c'est mal gérer", bien sûr même si c'est pas toujours évident quand on s'y met

pour les fuites mémoires c'est juste qu'ajax accentue le phénomène.
si on oublie d'éliminer les références à des objets/noeuds dom qui servent plus à rien, le ramesse miette ne fera plus son boulot.
sur une page où l'on reste dix seconde ça peut passer, mais au delà ça va s'accumuler vu qu'on est censé rester longtemps sur cette page.

pour la sécu c'est vrai qu'au boût du compte les failles se ressemblent, mais je trouve que la manière de gérer un appel xhr est un peu différente d'un submit de formulaire.

par contre pour se marcher sur les pieds c'est plus spécifique à la manière ajax.
en php on envoie tout sur le serveur, le traitement x se fait et on renvoie une page pour faire un traitement y, c'est synchrone.
en asynchrone on est susceptible d'acceder aux traitements x et y sur la même page en pouvant les déclencher "simultanément", ça rajoute le risque de se marcher sur les pieds qu'il n'y avait pas avec php tout court.

bref des problématiques auquelles j'ai été confronté (et que je partage ya pas de raisons) vu que pour certaines demandes c'était ce qu'il y avait de plus pratique à faire pour l'utilisateur

[Mobius]

Je tiens a souligner le fait que Ajax n'apporte rien de nouveau en soit !

C'est juste un terme qui remet a la une de l'actualité un ensemble de technologie (xml, dom, ...) saucé de beaucoup de Javascript (autour en particulier de l'objet xmlHttpRequest)
A mon avis ce qu'il manque c'est une méthodologie (bien que certain essaye de mettre ca en place) et des standard d'echange entre le client et le serveur (mais ca va un peu de pair avec la méthodologie.)

En résumé, c'est faire du neuf avec du vieu !

[Swoög]

+1 @ tout ce que dit Mobius [au passage c'est Moëbius normalement ]

@tthiery : Il est vrai que ça obligera les futurs version des navigateurs à faire plus attention à leur GB JavaScript... ^^

Pour les collision de traitements, les traitements sont généralements très rapides (un select sur une BDD, un update, etc...) donc je ne pense pas que ça soit véritablement un problème, même en asynchrone...