Un article en anglais bien intéressant qui parle un peu des technologies derrière gmail et autre google maps :
 
http://a9.com/ajax%20engine%20web%20javascript
 
En fait, il s'agit d'une présentation de ces méthodes qui apparaissent qui permettent de charger une page (ie de contacter le serveur) uniquement quand besoin est, cad lorsqu'on a besoin de nouvelles infos. Tous les autres traitements sont faits directement au niveau du navigateur du client. Du coup, la navigation est bien plus rapide et agréable.  
Si vous vous servez de gmail, c'est ce qui est utilisé pour "l'historique" des échanges de mails (envois/réponses déroulables trop trop vite).
 
Vous avez des connaissances plus concrètes que celles présentées dans ce document ? Qu'en est il par exemple de JPSAN pour php ? Y a t il d'équivalent Java ?
 
Merci d'avance !
ZedroS

si tu avais utilisé google au lieu de a9 tu aurais trouvé ca : http://www.adaptivepath.com/public [...] 000385.php
 

hmm, interessant; pas encore lu, mais je voulais justement en savoir plus sur leurs techniques. cela dit, gmail et gmaps, les deux ont des couacs assez casse couille et imprévisible.. je pense pas que ce genre de truc puisse etre utilisé dans des applis web "sensibles" (machins d'entreprise).. à voir.
(et puis niveau maintenance ça doit etre assez cauchemardesque ? )

Bon j'ai pas lu vos liens, mais j'ai peut-etre une petite idee de quoi ca parle.
 
Gmail utilise un objet disponible en JS qui est le XMLHttpRequest. Cet objet est diponible sous IE sous forme d'un objet ActiveX. Il est egalement disponible sous FF en tant qu'objet JS. Il est egalement disponible dans d'autres navigateur. Opera le possede egalement mais uniquement dans la derniere version, et son implementation bug encore un peu.
 
Mais pour info, ce n'est pas gmail, ni gmaps, qui ont "invente" ou "utilise" les premiers cet objet. Seulement google est plus grand, et du coup a eu plus de succes.
 
Va voir par la : http://blog.bitflux.ch/wiki/LiveSearch
Il utilise cet objet egalement.
 
Je ne connais pas "d'equivalent" jspan pour Java, mais tu en as pas besoin. Tu peux le faire toi.
 
[edit]
Avait oublie un "pas" dans la premiere phrase, ca le faisais moyen
[/edit]

 
Je me demandais justement si mes problèmes étaient des soucis isolés ou pas.. Perso, en fait, les soucis ne viennent pas tant des aspects Jscript mais plutot lors de la connexion (une fois login/mdp rentrés) : aucune page ne s'affiche... De là à dire que c'est dû à leur architecture "ajax", je suis moins sûr...
 

 
Pour moi qui utilise... Opera (le plus souvent), je te raconte pas la joie ! Comment ce fait il que ce XMLHttpRequest soit pas implanté de façon uniforme (vu qu'à priori gmail ne supporte qu'un nombre très restreint de navigateurs, j'en déduis que le code est spécifique à chacun ou... ?).
 

 
Hum... J'en suis aux servelts/jsp, pas trop encore les java scripts (si ce n'est les trucs basiques). Ceci dit j'y avais effectivement pensé, même si une structure préconcue aurait sans doute le mérite de me simplifier le travail. Autre point : y a t il moyen d'éviter ce traitement différent en fonction du navigateur ?  
 
En fait, toute la "magie" de leur approche est, si j'ai bien compris, de faire un nombre maximal de traitements sur le client, non ? Il n'y a pas besoin pour cela d'implémenter forcément du XMLHttpRequest, non ? Du java script "simple" peut déjà traiter une partie de la chose et limiter les appels serveur au strict minimum non ?

En fait l'objet est assez semblable entre IE et Moz, seule change la facon de le creer.
Enfin, il faut tout de meme nuancer, en effet, avec IE il y a quelques problemes. L'objet est un ActiveX, par consequent il n'est pas "lie" a la version du navigateur. Par consequent tu peux avoir un IE 5.5 avec la dernier version de l'objet (la 2 ou la 3, je sais plus). Et tomber apres sur un IE 6 avec la version 1 de l'objet, donc un peu "galere".
 
Neanmoins, toutes ces version fonctionnement de la meme maniere, seule change la facon d'initialiser l'objet, le JS specifique a chaque nav est donc assez petit.
 
XMLHttpRequest n'est utilise par gmail que pour faire des requetes sur le serveur. Donc pour aller chercher les mails ou verifier si un nouveau mail est arrive. Le reste est effectivement fait en JS, par exemple la "modification dynamique" de la page.
 
Autre information, il me semble que gmail fonctionne sur Opera. (Si c'est pas gmail, alors c'est LiveSearch qui fonctionne sur Opera). Or sur opera cet objet n'est pas implemente (sauf dans la derniere beta). La questione est de savoir comment ils ont fait pour "contourner" ce probleme.
En fait la reponse est "simple". Ils utilisent les fonctions DOM pour ajouter dynamiquement du contenu a la page.
 
En fait ce qu'ils font c'est qu'ils creent "a la volee" une balise "script" contenue dans le head. Cette balise script "pointe" vers la page qui doit retourner les informations depuis le serveur.
Une fois que le script est "charge" il "s'execute" afin d'appeler un "callback" et prevenir la page que le contenu est "arrive".
 
Je n'ai pas regarde le code de gmail, ni celui de LiveSearch, mais personellement j'aurais fait comme ca :
1) J'aurais cree un "objet" JS pour encapsuler la "creation" d'un "socket" (se terme est faux, mais je pense qu'il reprenste bien l'idee de ce que je veux faire). Lors de la creation, ce "socket" va tenter d'abord tenter d'initialiser l'activeX appelle XMLHttpRequest, on commence dont par IE (ceci pour une raison simple, il me semble que ce dernier plante si l'on essaye de creer l'objet sans avoir init l'activex...). On commence d'abord avec les "dernieres" version de l'activex pour "descendre" jusqu'a reussir a init l'objet. Si on a reussi on peut continuer.
Si on arrive pas a init l'activeX, cela veut dire que l'on est dans un autre navigateur, genre Moz. On essaye donc d'initialiser l'objet JS XMLHttpRequest. Si ca marche on conntinue.
Si ca marche pas, alors c'est que l'on doit etre sous Opera. Ici, personnellement j'utiliserais un objet JS perso qui va "imiter" XMLHttpRequest. Cet objet va faire en sorte que le code general de "comminication" reste identique aux trois navigateurs.
2) Une fois l'objet initialise, on peut continuer sans se soucier du navigateur (rappel, sous opera on utilise notre objet).
 
Opera: On va donc creer un objet JS qui va avoir la meme "interface" qu'XMLHttpRequest. Donc il aura les meme methodes, et fonctionnera de la meme facon, seule difference avec l'objet normal, c'est nous qui alons le construire.
Pour le faire fonctionner, on va donc utiliser les fonctions DOM afin d'ajouter un "script" dynamiquement a la page. Une fois ce script ajoute et "execute" il appelera notre fonction callback. Cette derniere va se charger de passer les donees a la fonction callback du code.
 
Il faut egalement preciser que l'objet XMLHttpRequest fonctionne egalement avec une fonction "callback" qui sera appelee une fois les donees arrivees.
 
 
Voila dans les grandes lignes, comment j'aurais implemente l'objet XMLHttpRequest pour qu'il fonctionne sur le plus de nav possibles. Je ne sais pas si gmail a fait comme ca, il me semble qu'ils ajoutent un script avec les fonction DOM sous opera, mais je me rappelle plus.
 
Si tu comptes utiliser cette methode, tu dois faire attention a plusieurs choses :
1) Il me semble que la plupart des navigateurs ont implemente une "securite" qui empeche de faire un "document.write('script');" ceci afin d'eviter des "attaques". C'est une espece de "mot tabou". Il me semble que cela risque de perturber l'ajout via la fonction DOM. Il existe neanmoins un contournement tres simple. En effet il suffit de faire "'scr'+'ipt'" afin de contourner le probleme. Il suffit de decouper le mot en deux.
2) Tu peux aller encore plus loin dans la "compatibilité" avec les anciens navigateurs. Par exemple, au lieu d'ajouter un script via les fonctions dom, tu peux ajouter une "iframe" invisible. Cette iframe devra pointer vers un fichier specifique cote serveur.
2b) Tu peux egalement aller plus loin si tu arrive a detecter cote serveur un navigateur qui ne supporte pas les fonctions d'ajout DOM. Tu peux lui servir un page "speciale". Du genre un page avec 2 frames. Une frame de taille 100% ou se trouve le site, et une autre de 0%. La 2e frame invisible, va te servir de "scriptframe" suffira de changer sa source dynamiquement pour "communiquer" avec le serveur.
 
Il est a noter que le support d'opera et des anciens navigateur va necessiter la creation d'un page specifique cote serveur. En effet cette page devra en fait etre un "contenant" pour le Javascript, qui lui meme sera un contenant pour l'information que tu veux transmetre. Alors qu'avec l'objet XMLHttpRequest tu n'as pas besoin de cette page conteneur ni du script conteneur.
 
 
Finallement un petit mot sur l'accessibilite. L'utilisation abusive de cet objet nuit gravement a l'accessibilite, et certaines des techniques que j'ai evoquees vont a l'encontre de "l'ethique" que devrait avoir un webmaster. Notament la 2b. En effet, le serveur web devrait servir la MEME page a TOUS les navigateurs.

\o/ j'était en avance sur mon temps lorsque j'ai écrit DLB \o/

Merci pour ces précisions, c'est complet à souhait !
Je vois mieux les enjeux même s'il faut encore que je me renseigne.  
 
Je trouve ca très regrettable qu'il n'ait pas de "méthode" à même de fonctionner pareillement avec tous les navigateurs.  
 
En fait, si j'ai bien compris, le problème se situe surtout au niveau des échanges client/serveur indépendants du chargement d'une nouvelle page, c'est ça ? Toute la question est alors "comment allez chercher les données" de façon transparente. Ceci dit pour des infos de "petites tailles", genre du texte, on pourrait l'uploader par avance non ?  
 
ps : gmail ne fonctionne pas sous Opera...

 
Oui. Et pour le moment, c'est d'ailleurs la seule solution raisonnable. Tu peux laisser tomber le reste à mon avis... C'est tout sauf accessible, même chez ceux qui ont JS mais n'ont pas IE ou une version récente de Mozilla/Firefox...

Un petit lien pour la route, qui complétera peut-être ce qui a déjà été dit (avec qq exemples notamment).
http://jibbering.com/2002/4/httprequest.html

Une dernière question qui me taraude : il n'y a qu'HTTPRequest pour faire des échanges asynchrones entre serveur et client ?
 
Je crains que oui mais bon ca me semble tellement fou...
 
Autrement dit, à part suite à une action de la personne qui a ouvert la page on ne peut pas l'actualiser à moins de tout recharger (via une actualisation automatique tous les X minutes), c'est bien ça ?

En effet, cela vient de la nature meme du protocole Http. Ce dernier est un protocole "deconnecte". En gros une fois que le server a envoye la page html la connexion est rompue. Donc il n'est plus possible d'envoyer un "message" au client a moins que ce dernier en fasse la "demande" (soit par XMLHttpRequest, soit via un moyen conventionnel).
 
Pour information il existe aussi une sorte de "hack" pour simuler un XMLHttpRequest. Cela s'appuye sur les cookies.
En fait ca fonctionne comme ca :
1) En JS on "cree" une image a la volee (ca pointe sur un php).
2) Lorsque le php recoit la requete pour l'image. Il envoi une image de 1px, MAIS il mets a jour un cookie chez le client. Ce cookie est utilise en tant que "passerelle".
3) Lorsque l'image est chargee, cela veut dire que les infos doivent se trouver dans le cookie, on lit alors le cookie en JS.
 
J'ai jamais teste en profendeur cette methode, mais il me semble qu'elle fonctionne. Je l'avais teste il y a quelques temps. Faudrait que je retrouve le "proof of concept"...
 
Bien que peux orthodoxe, cette methode aurait l'avantage de fonctionner quasiment partout (meme sur opera) (a condition que le JS soit active). Par contre inconvenient, le volume des donnees ne peut pas etre tres eleve (max 4 ko me semble).

J'ai l'impression qu'avec AJAX on revient au client lourd en fait ... pas vous ?
Mais lourd seulement côté visuel/interaction ... la couche métier ayant toujours lieu sur le serveur. Avec AJAX on améliore donc les applications côté client sans créer de déséquilibre de charge entre le client et le serveur.
Alors c'est fini les bonnes vieilles requête HTTP (HttpServletRequest)   et place à AJAX avec des clients plus interactifs (plus une application qu'une simple page statique HTML)

L'AJAX ce magnifique buzzword qui utilise des technologies vieilles d'au moins 5 ans est vraiment à la mode en ce moment
Tous les consultants et marketeux ne parlent que de ça. D'un coté ça a du bon pour ceux qui maitrisent bien le JS
mais d'un autre tout le monde se met a vendre des technos qu'ils ne maitrisent pas forcéments et vendent de la merde au final

On peut bien faire de "l'ajax" (entre  guillemets), juste faire une interaction client/Serveur sans avoir à recharger la page, sans avoir besoin de manipuler du XML

 
+1. C'est vieux comme le monde ce langage d'anarchiste de webmaster.
Sinon figure toi que "desactiver le javascript" c'est pas vraiment juste. En fait j'ai vu vendredi chez un pote qui a fait une appli entièrement en AJAX qu'il réussissait à activer le Javascript du navigateur quel que soit son état ! ... sous crainte que son site ne marche pas sinon . Car même les liens dans son site appellent une méthode JS.

Tu as craqué ?
Quand le JS est désactivé, il est vraiment désactivé, sinon c'est qu'il ne l'avait pas vraiment désactivé.

 
Non non, il me l'a démontré devant mes yeux. Attends que je le recontacte.
 
EDIT : puis je dirais presque que c'est de la connerie cette histoire de désactivation du JS car plein de sites utilisent JS. Le désactiver, c'est de déconnecter d'Internet .

Oui recontacte le
car faut être benêt pour croire une chose pareil.
 
que je sois sous IE/FF/Opera, je desactive le JS et il est vraiment désactivé

C'est même l'article qui a créé le terme "AJAX"
 
Accessoirement, il va sur sa 2e année là...
 
Si tu veux un blog sur ce genre de trucs, vas voir http://ajaxian.com/ . Il est néamoins loin d'être idéal, parce qu'on y trouve du très bon comme du très mauvais, et principalement du très mauvais.
 
Pour quelques infos accessoires, http://www.adambosworth.net/archives/000044.html http://www.contentwithstyle.co.uk/ [...] -ajax-apps http://blog.monstuff.com/archives/000250.html (et tout le blog de Julien Couvreur en général en fait: http://blog.monstuff.com/ ). Mon PC principal est en rade, donc j'ai rien d'autre pour le moment.
 
Mais fondamentalement, "AJAX" ce n'est rien de plus que l'utilisation de Javascript et de l'objet XMLHttpRequest pour effectuer des communications entre ton script et ton serveur. En gardant à l'esprit que par défaut XMLHttpRequest est asynchrone, avec tout ce que ça implique.
 

Bof, ça dépend des cas.

C'est une blague?
 
Opera implémente XMLHttpRequest en natif depuis Opera 7.60b
 
La dernière version, c'est la 9.01

C'est même strictement le même pour la majorité des utilisations, dans la mesure où MS a créé XMLHttpRequest (dans IE5, à la base il avait été créé pour Outlook Web Access 2000) et où toutes les autres implés sont issues du reverse-engineering  de l'objet créé par MS.

Il est possible d'extraire les principes d'un article sans en utiliser précisément les techniques hein
 
Factuellement, faire de l'AJAX sans utiliser de XML est probablement bien plus intelligent que l'inverse

Bien sûr que si, et je vais t'apprendre un truc: il existe des navigateurs ne gérant pas le javascript!
Et accessoirement, pas mal de boites désactivent partiellement ou totalement le support de scripting dans leurs navigateurs (JS et VBS), à minima pour la zone internet, afin d'éviter de potentiels problèmes de sécurité.

Mais oui bien sûr

Ton pote est un crétin

Tu le fais exprès ou tu veux juste troller
 
PS: https://addons.mozilla.org/ oooh, mais quelle est donc le but de la 2e extension firefox la plus populaire
 
edit: erreur de buzzword

Nan puisque tu as une utilisation du composant principal
l'objet XmlHttpRequest te permet de recuperer un élément avec du contenu texte tout cours ou du contenu XML (que tu peux parser avec le DOM facilement).
Mais dire que c'est du simple JS est faux

Ajax ca peut etre utile pour faire un effet sympa pour le user. Mais il faut avoir l'alternative au cas ou il n'y a pas JS sur le browser

Tu devrais songer à arrêter la drogue je pense

En même temps c'est surtout le véritable nom du truc, dans la mesure où les navigateurs MS implémentent non le javascript mais le JScript.

Ah ouais là faudrait songer à la désintox quand même.
 
Hint: l'utilisation de XMLHttpRequest, que ce soit avec un format de transfert en HTML, en XML ou en JSON, précède de 5 ans la naissance de l'acronyme "AJAX"...
 
"AJAX", c'est du javascript, rien de plus et rien de moins, la différence c'est qu'AJAX c'est marketroïd compliant (comme Web2.0) .

Dans la pratique on est peut etre loin du mot XML.
Mais néanmoins ca reste de l'AJAX dans les grand sens du terme.
 

Ecmascript c'est la normalisation de tout ce beau merdier, afin de ne pas sombrer dans des variantes farfelues du langage.
Et sache Jeune enfant que l'Ecmascript a quelques débouchés.  
- Javascript/Dom
- ActionScript
 

http://www.ecma-international.org/ [...] ma-262.htm          
 

Nan pas totalement

Non.

Absolument pas

Ptin mais jamais t'arrêtes?
http://www.ecma-international.org/ [...] ma-262.htm

Non, si on code des scripts compatibles JScript et Javascript on code dans le standard commun implémenté par les deux langages, qui est l'ECMAScript.
 
De même qu'on peut coder en C++ si on suit le standard ISO/IEC 14882:2003 et être plus ou moins compatible avec tous les compilos implémentant ce standard, ou bien on peut coder en Borland C++, en G++/GCC C++ ou en Visual C++ si l'on utilise des fonctionalités non standard propriétaires aux différents compilateurs.