Modifier l'URL de la barre d'adresses dans l'application AJAX pour correspondre à l'état actuel

J'écris une application AJAX, mais au fur et à mesure que l'utilisateur se déplace dans l'application, j'aimerais que l'URL de la barre d'adresse se mette à jour malgré le manque de recharges de page. En gros, j'aimerais qu'ils soient en mesure de créer un signet à tout moment et de revenir ainsi à l'état actuel.

Comment les gens gèrent-ils le maintien de RESTfulness dans les applications AJAX?

La façon de faire est de manipuler location.hashlorsque les mises à jour AJAX entraînent un changement d'état que vous souhaitez avoir une URL discrète. Par exemple, si l'URL de votre page est:

http://example.com/

Si une fonction côté client a exécuté ce code:

// AJAX code to display the "foo" state goes here.

location.hash = 'foo';

Ensuite, l'URL affichée dans le navigateur serait mise à jour pour:

http://example.com/#foo

Cela permet aux utilisateurs de mettre en signet l'état «foo» de la page et d'utiliser l'historique du navigateur pour naviguer entre les états.

Avec ce mécanisme en place, vous devrez ensuite analyser la partie hachée de l'URL côté client à l'aide de JavaScript pour créer et afficher l'état initial approprié, car les identificateurs de fragment (la partie après le #) ne sont pas envoyés au serveur.

Le plugin hashchange de Ben Alman fait de ce dernier un jeu d'enfant si vous utilisez jQuery.

Regardez des sites comme book.cakephp.org. Ce site modifie l'URL sans utiliser le hachage et utilise AJAX. Je ne sais pas comment cela fonctionne exactement, mais j'ai essayé de le comprendre. Si quelqu'un sait, faites le moi savoir.

Aussi github.com lorsque vous regardez une navigation dans un certain projet.

Il est peu probable que l'auteur veuille recharger ou rediriger son visiteur lors de l'utilisation d'Ajax. Mais pourquoi ne pas utiliser HTML5 pushState/ replaceState?

Vous pourrez modifier la barre d'adresse autant que vous le souhaitez. Obtenez des URL d'apparence naturelle, avec AJAX.

Consultez le code de mon dernier projet: http://iesus.se/

Ceci est similaire à ce que Kevin a dit. Vous pouvez avoir l'état de votre client en tant qu'objet javascript, et lorsque vous souhaitez enregistrer l'état, vous sérialisez l'objet (en utilisant le codage JSON et base64). Vous pouvez ensuite définir le fragment de href sur cette chaîne.

var encodedState = base64(json(state));
var newLocation = oldLocationWithoutFragment + "#" + encodedState;

document.location = newLocation; // adds new entry in browser history
document.location.replace(newLocation); // replaces current entry in browser history

La première méthode traitera le nouvel état comme un nouvel emplacement (le bouton de retour les amènera donc à l'emplacement précédent). Ce dernier ne le fait pas.

SWFAddress fonctionne dans les projets Flash et Javascript et vous permet de créer des URL de signet (en utilisant la méthode de hachage mentionnée ci-dessus) ainsi que de vous donner la prise en charge des boutons de retour.

http://www.asual.com/swfaddress/

La méthode window.location.hash est la manière préférée de faire les choses. Pour une explication sur la façon de le faire, Ajax Patterns - URL uniques .

YUI a une implémentation de ce modèle en tant que module, qui comprend des travaux spécifiques à IE pour faire fonctionner le bouton de retour avec la réécriture de l'adresse à l'aide du hachage. Gestionnaire de l'historique du navigateur YUI .

D'autres frameworks ont également des implémentations similaires. Le point important est que si vous voulez que l'historique fonctionne avec la réécriture de l'adresse, les différents navigateurs ont besoin de différentes manières de la gérer. (Ceci est détaillé dans le premier article de lien.)

IE a besoin d'un hack basé sur iframe, où Firefox produira un double historique en utilisant la même méthode.

Si OP ou d'autres recherchent encore un moyen de modifier l'historique du navigateur pour activer l'état, utiliser pushState et replaceState, comme suggéré par IESUS, est la `` bonne '' façon de le faire maintenant. Son principal avantage par rapport à location.hash semble être qu'il crée des URL réelles, pas seulement des hachages. Si l'historique du navigateur à l'aide des hachages est enregistré, puis revisité avec javascript désactivé, l'application ne fonctionnera pas, car les hachages ne sont pas envoyés au serveur. Cependant, si pushState a été utilisé, la route entière sera envoyée au serveur, que vous pouvez ensuite créer pour répondre de manière appropriée aux routes. J'ai vu un exemple où les mêmes modèles de moustache étaient utilisés à la fois du côté serveur et du côté client. Si le client avait activé javascript, il obtiendrait des réponses rapides en évitant l'aller-retour vers le serveur, mais l'application fonctionnerait parfaitement sans javascript. Ainsi, l'application peut se dégrader gracieusement en l'absence de javascript.

De plus, je pense qu'il existe un cadre, avec un nom comme history.js. Pour les navigateurs prenant en charge HTML5, il utilise pushState, mais si le navigateur ne le prend pas en charge, il revient automatiquement à utiliser des hachages.

Vérifiez si l'utilisateur est «dans» la page, lorsque vous cliquez sur la barre d'url, javascript indique que vous êtes hors de la page. Si vous changez la barre d'url et appuyez sur 'ENTRER' avec le symbole '#' à l'intérieur, vous revenez dans la page, sans cliquer manuellement sur la page avec le curseur de la souris, puis une commande d'événement de chargement de touches (document.onkeypress) de javascript sera être en mesure de vérifier si c'est entrer et activer le javascript pour la redirection. Vous pouvez vérifier si l'utilisateur est dans la page avec window.onfocus et vérifier s'il est dehors avec window.onblur.

Ouais, c'est possible.

;)