Question

Gmail utilise # lorsque vous cliquez sur un courrier pour distinguer la page (action + Ajax). http://mail.google.com/mail/#inbox/1238e709e37a1394

j'ai trouvé: Google utilisant # au lieu de recherche? dans l'URL. Pourquoi?

Dans FF ou Chrome, vous pouvez utiliser les fonctions Avance et Retour sans actualisation entre ces URL: http://X.com/MyPage.aspx#1 http://X.com/MyPage.aspx#2 http://X.com/MyPage.aspx#3

Mais sur IE, la page est actualisée et ne compte pas les paramètres après # quand une action arrière est effectuée.

Comment Gmail crée la magie?

Était-ce utile?

La solution 2

Autres conseils

Je peux vous donner la réponse à cette question, car j'ai affronté et résolu ce problème.

Il y a quelques concepts à comprendre ici en premier:

  1. javascript ne peut pas modifier directement l'historique du navigateur.
  2. chaque fois que l'URL de base d'un iframe dans la page change, l'historique est mis à jour. (mais cela a quelques bizarreries avec différents navigateurs).
  3. l'url a un " haché " partie: par exemple, dans l'URL http://mail.google.com/mail#inbox , #inbox correspond à la partie hachée. Appelons cela le "hash". si http://mail.google.com/mail sera notre "URL de base".

L’historique des suivis par GMail se fait principalement à l’aide d’astuces basées sur ce "hash".

Donc, quelques concepts supplémentaires:

  1. lorsque l'URL de la barre d'adresse change, l'historique est mis à jour (l'URL précédente est enregistrée dans l'historique)
  2. lorsque l'URL de base est modifiée, la page est rechargée.
  3. lorsque la partie de hachage de l'URL change sans changer l'URL de base, la page n'est pas rechargée.

Ainsi, lorsque vous passez de http://mail.google.com/mail#inbox à http://mail.google.com/mail#sent , la page n'est pas actualisée .

Désormais, si GMail recevait une notification d'événement lorsque le hachage était modifié, alors Gmail pourrait prendre des mesures en conséquence. Malheureusement, aucun événement DOM ne peut nous aider à capturer des actions de l'historique. Donc au lieu de cela (c'est la partie qui montre comment j'ai résolu le problème), nous exécutons une boucle infinie qui vérifie les modifications apportées au hachage. S'il constate un changement, nous détectons un clic sur le bouton "retour". ou " forward " bouton du navigateur.

Pour résoudre ce problème, j'ai créé un outil pratique: l’ analyseur d’URL . Il peut analyser les paramètres GET dans l'URL, ainsi que les paramètres encodés dans le hachage. Lancez la démo!

Salut!

À propos de ce problème dans IE: je ne savais pas que cette solution basée sur le «hachage» ne fonctionnait pas sous IE (mauvais développeur Linux).

Mais pour IE, vous pouvez utiliser une iframe cachée et son URL "affecte l'historique". propriété d'implémenter l'histoire. Je sais que cette déclaration manque de détails, mais cela vient de mon manque d'expérience avec IE.

Je vais essayer cette solution et faire un suivi:)

J'ai trouvé une multitude de liens sur Internet qui implémentent correctement l'historique en utilisant un hachage iframes / location. Je n’ai pas eu la patience de creuser les différences entre les interfaces iframe sur différents navigateurs.

Je pense que je préférerais le plug-in jquery . YUI a aussi un gestionnaire d’histoire.

Salut!

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top