Dans le cas d’une application Ajax, si la page contenant la structure XHTML et ses
scripts client (moteur Ajax, gestionnaire d’événement…) est chargée de la même
manière que pour un site statique, il n’en est pas de même pour les interactions qui
suivent entre le navigateur et le serveur. Le moteur Ajax une fois chargé dans le navigateur
restera en attente de l’événement pour lequel il a été programmé. Pour cela,
un gestionnaire d’événement JavaScript est configuré pour appeler le moteur dès
l’apparition de l’événement concerné. Lors de l’appel du moteur, un objet XMLHttp-
Request est instancié puis configuré, une requête asynchrone est ensuite envoyée au
serveur. À la réception de celle-ci, le serveur démarrera son traitement et retournera la
réponse HTTP correspondante. Cette dernière sera prise en charge par la fonction de
rappel du moteur Ajax qui exploitera les données pour les afficher à un endroit précis
de l’écran.
Chronogrammes des échanges client-serveur
Une des grandes différences entre une application Web traditionnelle et une application
Ajax est liée à l’échange asynchrone de données entre le navigateur et le serveur. Pour
vous permettre de bien appréhender la différence entre ces deux applications, nous vous
proposons de les comparer maintenant à l’aide de leur chronogramme.
Chronogramme d’une application Web dynamique traditionnelle
Lorsqu’un utilisateur sollicite le serveur dans une application Web dynamique traditionnelle
(en envoyant un formulaire ou en cliquant sur une URL dynamique), il
déclenche une requête HTTP dans laquelle sont imbriqués les paramètres de la demande.
À partir de ce moment, le navigateur se fige jusqu’à la réception de la réponse HTTP
du serveur, interdisant ainsi à l’utilisateur toute action pendant le temps de traitement
de la requête. Dès la réception de la requête, le serveur Web analysera les paramètres et
traitera la demande selon son programme. Il pourra interroger un serveur de base de
données pour recueillir des données complémentaires si nécessaire. Une fois le traitement
terminé, une page HTML complète sera construite à la volée, incluant les résultats
du traitement après leur mise en forme. Cette page sera alors retournée au navigateur
après son intégration dans le corps de la réponse HTTP. À la réception de la réponse
HTTP, le navigateur interprétera la page HTML, comme lors de l’appel d’une page Web
dans un site statique, et l’affichera à l’écran, entraînant le rechargement complet de la
page. À la fin du chargement de la page, le navigateur est débloqué et l’utilisateur
reprend la main sur l’application. Il pourra ainsi éventuellement réitérer une nouvelle
demande serveur qui suivra le même cycle de traitement que celui que nous venons de
décrire.
Chronogramme d’une application Ajax en mode asynchrone
Dans le cas d’une application Ajax en mode asynchrone, le déroulement du traitement est
différent. À noter que l’objet XMLHttpRequest peut aussi envoyer des requêtes synchrones,
mais dans ce cas le fonctionnement serait semblable à celui d’une application Web dynamique
traditionnelle comme celle que nous avons décrite précédemment.
Dans une application Ajax, l’utilisateur doit commencer par appeler la page HTML
contenant le moteur Ajax. Une fois la page chargée dans le navigateur, les échanges avec
le serveur seront contrôlés par l’application Ajax (voir suivent). L’envoi d’une requête
est souvent déclenché par un gestionnaire d’événement JavaScript, mais il peut aussi être
généré par un script de temporisation pour actualiser des informations à intervalles réguliers.
Quel que soit le mode de déclenchement, le moteur Ajax est appelé par le biais
d’une fonction JavaScript. La première action du moteur est la création d’un objet
XMLHttpRequest immédiatement suivi de sa configuration (choix de la méthode de
transfert GET ou POST, choix du fichier serveur sollicité, activation du mode asynchrone,
désignation d’une fonction de rappel, intégration des paramètres…). Une fois
l’objet configuré, l’envoi de la requête est déclenché, générant une requête HTTP
semblable à celle créée avec une application dynamique traditionnelle. Toutefois, dans le
scripts client (moteur Ajax, gestionnaire d’événement…) est chargée de la même
manière que pour un site statique, il n’en est pas de même pour les interactions qui
suivent entre le navigateur et le serveur. Le moteur Ajax une fois chargé dans le navigateur
restera en attente de l’événement pour lequel il a été programmé. Pour cela,
un gestionnaire d’événement JavaScript est configuré pour appeler le moteur dès
l’apparition de l’événement concerné. Lors de l’appel du moteur, un objet XMLHttp-
Request est instancié puis configuré, une requête asynchrone est ensuite envoyée au
serveur. À la réception de celle-ci, le serveur démarrera son traitement et retournera la
réponse HTTP correspondante. Cette dernière sera prise en charge par la fonction de
rappel du moteur Ajax qui exploitera les données pour les afficher à un endroit précis
de l’écran.
Chronogrammes des échanges client-serveur
Une des grandes différences entre une application Web traditionnelle et une application
Ajax est liée à l’échange asynchrone de données entre le navigateur et le serveur. Pour
vous permettre de bien appréhender la différence entre ces deux applications, nous vous
proposons de les comparer maintenant à l’aide de leur chronogramme.
Chronogramme d’une application Web dynamique traditionnelle
Lorsqu’un utilisateur sollicite le serveur dans une application Web dynamique traditionnelle
(en envoyant un formulaire ou en cliquant sur une URL dynamique), il
déclenche une requête HTTP dans laquelle sont imbriqués les paramètres de la demande.
À partir de ce moment, le navigateur se fige jusqu’à la réception de la réponse HTTP
du serveur, interdisant ainsi à l’utilisateur toute action pendant le temps de traitement
de la requête. Dès la réception de la requête, le serveur Web analysera les paramètres et
traitera la demande selon son programme. Il pourra interroger un serveur de base de
données pour recueillir des données complémentaires si nécessaire. Une fois le traitement
terminé, une page HTML complète sera construite à la volée, incluant les résultats
du traitement après leur mise en forme. Cette page sera alors retournée au navigateur
après son intégration dans le corps de la réponse HTTP. À la réception de la réponse
HTTP, le navigateur interprétera la page HTML, comme lors de l’appel d’une page Web
dans un site statique, et l’affichera à l’écran, entraînant le rechargement complet de la
page. À la fin du chargement de la page, le navigateur est débloqué et l’utilisateur
reprend la main sur l’application. Il pourra ainsi éventuellement réitérer une nouvelle
demande serveur qui suivra le même cycle de traitement que celui que nous venons de
décrire.
Chronogramme d’une application Ajax en mode asynchrone
Dans le cas d’une application Ajax en mode asynchrone, le déroulement du traitement est
différent. À noter que l’objet XMLHttpRequest peut aussi envoyer des requêtes synchrones,
mais dans ce cas le fonctionnement serait semblable à celui d’une application Web dynamique
traditionnelle comme celle que nous avons décrite précédemment.
Dans une application Ajax, l’utilisateur doit commencer par appeler la page HTML
contenant le moteur Ajax. Une fois la page chargée dans le navigateur, les échanges avec
le serveur seront contrôlés par l’application Ajax (voir suivent). L’envoi d’une requête
est souvent déclenché par un gestionnaire d’événement JavaScript, mais il peut aussi être
généré par un script de temporisation pour actualiser des informations à intervalles réguliers.
Quel que soit le mode de déclenchement, le moteur Ajax est appelé par le biais
d’une fonction JavaScript. La première action du moteur est la création d’un objet
XMLHttpRequest immédiatement suivi de sa configuration (choix de la méthode de
transfert GET ou POST, choix du fichier serveur sollicité, activation du mode asynchrone,
désignation d’une fonction de rappel, intégration des paramètres…). Une fois
l’objet configuré, l’envoi de la requête est déclenché, générant une requête HTTP
semblable à celle créée avec une application dynamique traditionnelle. Toutefois, dans le





Aucun commentaire:
Enregistrer un commentaire