L’un des soucis avec les sites full ajax provient de la navigation entre les différentes pages : charger du contenu dans une page en asynchrone est de plus en plus employé mais suppose que l’on perde l’historique du navigateur. Si vous cliquez sur un lien chargeant du contenu à la place de l’existant, vous perdez celui-ci, logique. Comment revenir en arrière et retrouver le contenu d’origine ? Pas possible. Mais on peut y remédier.
The sequence of Documents in a browsing context is its session history
Du coup, certains développeurs ont trouver la parade : utiliser le système d’ancre d’HTML pour simuler le changement d’url monsite.com/#monAjax avec la fonction javascript hashChange. D’autres sont allés plus loin en utilisant une réécriture côté navigateur avec un interpréteur côté serveur : c’est le cas de Twitter par exemple avec https://twitter.com/#!/webdevlint correspondant à https://twitter.com/webdevlint
Le seul soucis dans les deux cas, vous l’aurez deviné c’est l’absence de dégradation (ou fallback) en l’absence de Javascript.
Chose réglée dans le cas où vous travaillez avec Ajax comme dans mon article précédent : AJAX: comment bien inclure une page en ajax ? et l’utilisation de l’Api history d’HTML5.
Dans mon post précédent, je vous parlais d’inclusion de contenu asynchrone grâce à jQuery qui envoie l’entête X_REQUESTED au serveur (Apache ici) ; dans notre code PHP nous indiquons à Apache qu’il ne doit nous retourner que ce que nous avons déclaré comme étant du contenu asynchrone grâce à :
if($_SERVER['HTTP_X_REQUESTED_WITH']=='')Nous construisons notre menu tout à fait normalement en pointant vers notre page complète, mais nous utilisons notre fonction JS pour insérer le contenu en Ajax.
Avec l’Api History, nous pouvons aller plus loin :
if (history && history.pushState) {
history.pushState({ path: this.path }, '', this.href);
}Au moment où nous faisons notre requête ajax dans notre script, sur le callback complete ou success de la fonction $.ajax de jQuery, nous faisons un changement d’url dans la barre URL du navigateur (et donc dans son historique) si l’appel.
Si notre lien est http://devlint.fr/maPage.html, alors nous envoyons au navigateur :
history.pushState({ path: this.path }, '', 'http://devlint.fr/maPage.html');ainsi tout en ayant une navigation animée en asynchrone, nous conservons en apparence une navigation dite classique dans laquelle l’utilisation des boutons du navigateur (précédent / suivant).
Ca c’est le schéma simpliste : il faut prévoir l’action JS sur l’événement history.popstate – par exemple, l’action du bouton précédent history.back() ; prévoir un fallback pour les navigateurs qui ne supporte pas HMTL5 et cette Api ; par contre rien n’est à prévoir lorsque javascript n’est pas activé puisque notre application utilise de vrais liens… chaque lien étant une requête complète au serveur.
A suivre donc dans un lab dès que j’ai un peu de temps.
Quelques liens pour compléter mes propos :
- http://www.w3.org/TR/html5/history.html
- https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history
- http://html5demos.com/history
- http://diveintohtml5.org/history.html
- Introducing the HTML5 History API