Version imprimable
Bonjour,
Avant deux min, j avais l idée que AJAX est un language de programmation comme php :oops:
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.
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.
>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 :mrgreen:
oui, j'avais plus le nom exact du truc en tête ;)Citation:
Envoyé par tthierry
si c'est mal géré oui ^^Citation:
Envoyé par tthiery
ah bon !? j'aurais plutôt dit l'inverse...Citation:
Envoyé par tthiery
je vois pas en quoi c'est spécifique à AJAX...Citation:
Envoyé par tthiery
!? encore une fois, si c'est bien fait je vois pas pourquoi ça serait le cas.Citation:
Envoyé par tthiery
que nous ne sommes d'ailleurs pas obliger d'utiliser :DCitation:
Envoyé par tthiery
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 ;)
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 !
+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...
[HS]effectivement normalement c'est Moëbius mais on trouve se nom sous différentes orthographe (notement Mobius et Möbius). Et perso j'ai fait mon choix meme si c'est pas l'orthographe du plus connus (celui auquel correspond mon avatar)[/HS]
>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...
je t'assure que si (ça dépend évidemment des actions), un click aussi c'est très rapide...donc faut le gérer c'est tout.
>Il est vrai que ça obligera les futurs version des navigateurs à faire plus attention à leur GB JavaScript... ^^
rien à voir, ce dont je parle c'est un problème de prog qui se retrouve dans tous les languages.
si tu crés un objet 'toto' qui référence un objet 'tutu', c'est pas en détruisant tutu que toto sera candidat au gb.
là c'est clair, mais si on mélange le tout avec le dom qui se modifie constament, les objet qui affichent, requête, gèrent les événements et plein d'autres trucs... on arrive (ou pas) au besoin de méthodologie dont parles mobius... (ça me rappel mes cours sur les clients riches)
et pour la charge serveur on peut faire une multitude de click (donc d'appels) en très peu de temps (je parlais pas du poids d'une page), là aussi faut stopper les ardeurs :D
Chose qui peut arriver aussi sans ajax... aucun rapport... niveau charge du serveur ajax à l'avantage d'économiser de la bande passante... .. .Citation:
Envoyé par tthierry
@ tchaOo°
>Chose qui peut arriver aussi sans ajax... aucun rapport... niveau charge du serveur ajax à l'avantage d'économiser de la bande passante... .. .
bande passante, serveur, on peut arriver aussi...tu me permets de chipoter un coup, je ne crois pas que l'on parle de la même chose ;)
si on oublie la bande passante et que l'on regarde la charge sur un sgbd.
si chaque click engendre une requête, est ce que sur une appli classique on pourra engendrer autant d'appel base que sur une appli ajax ?
un des exemples les plus connus est le système d'autocompletion où il est préférable de faire un appel base toutes les deux lettres pour ne pas trop abuser.
donc pour la bande passante je suis d'accord avec toi, pour le reste tu ne m'as pas convaincu qu'il n'y ait pas de rapport entre ajax et une charge serveur à laquelle il faut faire attention.
Ya quand meme une chose que tu oublie tthierry, c'est que dans beaucoup de cas, ajax permet simplement de remplacer des liens sur les pages et donc ca permet d'eviter de rafraichir l'ensemble de la page !
c'est vrai aussi que tu peux envoyer des requetes a chaque évènement (pour t'amuser ou si t'es un peu con et que tu veux surcharger le serveur) mais c'est pas tellement le but. Comme toujours on peut faire n'importe quoi avec n'importe quoi. (N'a t on pas dit que la programmation object allait simplifier les choses ? Pourtant j'ai vu beaucoup de programme utilisant un langage object bcp moins lisible et "propre" que d'autre fait dans un langage non-objet)
Au final, c'est toujours pareil, on te met a disposition des outils, méthodes ou autres, et tu en fait un peu ce que tu veux (de vrai bijou comme de belle merde !)
Le problème n'est pas lié a ajax mais de la personne qui l'utilise. Cette meme personne aura beau faire autrement, de facon plus classique ou conventionnel, je paris que le résultat ne sera pas mieu !
rhooo :roll:
au départ je me suis amusé à relever certains points qui me donnent mal à la tête vu qu'en ce moment je suis en train d'approfondire le sujet.
après si faut se la jouer sérieux pourquoi pas, mais pour le trois quart des objections je n'y vois que des poncifs dits et redits...je comprend pas très bien l'intérêt.
sinon bien sûr que j'utilise cette méthode de dev parceque c'est à la mode.
bien sûr que je parle d'objet pour me la raconter.
bien sûr qu'ajax n'a rien à voir avec de la programmation événementiel.
bien sûr qu'il vaut mieux ne pas sortir de chez soi au risque de se faire écraser.
donc oui il y a mille et une façon d'aborder les choses, et après...
dans tous les cas j'ai l'impression d'avoir entamé un dialogue de sourd, peut-être que le mieux serait de comparer l'utilisation que l'on en fait.
pour ma part je m'y suis mis il y a huit mois suite à une demande d'ajout de fontionnalité dans un back office.
après analyse, si j'avais envie de faire en sorte de faciliter la vie de l'utilisateur j'avais pas trop le choix.
depuis j'y trouve pas mal d'intérêts et toutes les problématiques que j'ai soulevé sont celles auxquelles j'ai été confronté.
je m'en sert essentiellement dans une approche évènementiel (un click -> un appel serveur)...sinon on appel ça du dhtml.
une autre approche est aussi de faire une appli en ligne (ce que je n'ai pas fait) comme gmail ou des tableurs et traitement de texte en ligne...mais c'est aussi une des finalités (une page qui contient tout).
en plus ça permet de casser la routine d'un dev php classique, ça aussi j'aime bien.
bah tu vois quand tu veux :lol:
Ceci dit je suis entierement d'accord que c'est un effet de mode et que dans la plupart des cas on s'attire plus d'emmerde qu'autre chose
hého!! quelqu'un m entend??, :cry: vous m'avez oublié moi et c est pas vraiment joli de se sentir comme ça loin de tout monde bouche bé devant tout ce que vous venez de dire :roll:
c est vrai que je connais des choses sur l informatique, et j ai essayé de comprendre ajax mais hélas j ai pas compris grand chose :(
Si ça ne vous derange pas, quelqu'un peut me donner, une comparaison avec un X comme lui?
Par exemple si c un language, on peut dire que c est comme php. Si c est une methode de conception, on peut comme UML ou Merise ...
J'espere que vous m'avez compris? comme ça moi je peux faire une bonne recherche.
Merci d avance
merci pour le troll
C'est une technique de développement dirons-nous...
un peu comme... par exemple les design patterns en POO... ou les formulaires en HTML...
:)
c'est un méthode de programmation.
c'est un mix entre l'utilisation d'un langage serveur (php, jsp, asp,...) et de javascript.
à l'aide de javascript tu peux communiquer avec le serveur (via l'objet xmlhttprequest).
les résultats sont renvoyés au format texte ou xml pour avoir quelquechose de plus structuré (cas où tu dois recevoir beaucoup de données).
le fichier xml peut être parsé par js via les méthodes du dom.
ensuite grâce à ces infos tu peux modifier la page html en utilisant le dom et le css (du dhtml).
ça permet de modifier une page avec les infos du serveur sans avoir à la recharger.
en gros c'est ça, mais si tu fouilles le net tu pourras avoir plus d'infos.
:lahola: Merci mille fois pour vos réponses, maintenant ça sera facile ma recherche ainsi que la comprehension :)
Merci pour tout je suis vraiment contente ;)
Si vous avez autre chose à ajouter sur ce sur là, je suis preneuse :mouarf: bien sur