History.js Hash-Fallbacks in Internet Explorer und pushState Problem

Question

Ich implementiere eine Website, die ihre URLs dynamisch mit History.js erstellt, wenn neue Abschnitte über Ajax auf die Startseite geladen werden.

Dies scheint gut zu funktionieren, aber es gibt ein Problem mit dem Hash-Abschnitt in der URL, die History.js als Fallback in Internet Explorer erstellt.

Hier Beispiele für Links auf der Seite sind, erstellt mit Jquery:

function connect_browse_buttons(){ 
    $('.browselink').each(function(){ 
     $(this).click(function(){ 
      var action = $(this).attr('name'); 
      action = action.substring(('action_browse').length); 
      browsetype = action; 
      if (isIE){ 
       // remove data object and title to avoid use of SUIDs by History.js in IE 
       History.pushState(null, null, '/public/' + action); 
      } else { 
       History.pushState({oldurl: History.getState()['url']}, "Example " + action, config.wwwroot + "public/" + action); 
      } 
      return false; 
     }); 
    }); 
} 

Die .htaccess-Datei alle Urls wie http://example.com/public/category_a-http://example.com umleitet, wo die Javascript, um die URL analysiert und lädt den entsprechenden Abschnitt über Ajax Anforderungen im ChangeState-Handler.

Die Javascript-Kontrollen für Urls wie

http://example.com/public/category_a 

UND für gleichwertige Ausweich URLs in Internet Explorer erstellt, das heißt

http://example.com/#public/category_a 

Das alles funktioniert OK - So:

In Firefox, wenn ich die Website im Stammverzeichnis der Website öffnen, http://example.com, und klicken Sie auf einen Link wie oben, den Inhalt lo

http://example.com/public/category_a 

Wenn ich dann auf einem anderen Link die URL wie zum Beispiel Set klicken Sie auf: Anzeigen (in dem change Handler) und die URL werden von History.pushState nach

http://example.com/public/category_b 

in IE, wenn ich die Stelle an der Wurzel der Site zu öffnen, und klicken Sie auf einen Link, nach oben, um die Inhaltslasten und die uRL mit einem Hash-set als:

http://example.com/#public/category_a 

wenn ich dann cl ick auf dem folgenden Link, wird die URL gesetzt, wie:

http://example.com/#public/category_b 

Das Problem entsteht wenn ich eine Seite im Internet Explorer öffnen, die in Firefox Lesezeichen wurden, und nicht über den Hash in der URL. Lassen Sie sich unser übliches Beispiel nehmen: erfolgreich

http://example.com/public/category_a 

Wenn ich diese URL direkt in IE öffnen, über ein Lesezeichen oder durch die URL in der Browser-Adressleiste einfügen, leitet die .htaccess, wird die URL durch die js OK analysiert Datei und der Inhalt lädt. Aber jetzt, wenn ich auf dem category_b Link klicken, wird die URL-Satz von History.pushState zu:

http://example.com/public/category_a#./category_b 

Was ich wirklich wollte, war die URL als gesetzt:

http://example.com/#public/category_b 

jedoch Geschichte. js scheint die gesamte vorherige URL als Basis-URL für nachfolgende Push-Zustände zu verwenden. Ich habe versucht, absolute URLs in History.pushState zu setzen, aber ohne Erfolg. Wie Sie im Codeblock oben sehen können, habe ich eine IE-spezifische pushState-Anweisung. Ich habe versucht, dies auf verschiedene Arten zu konfigurieren.Wie kann ich Geschichte pushstate zu erkennen:

http://example.com 

als das Basisteil der URL, die der Hash-Abschnitt soll angehängt werden? Oder gibt es eine bessere Möglichkeit, sich dieser zu nähern als die oben beschriebene?

Answer 1

AFAIK, die History-API wird immer die gesamte URL (sans-Hash) verwenden, die für die anfängliche Seitenladung angefordert wurde. Sobald die Seite geladen ist, können Sie mithilfe der History-API Änderungen nach der ursprünglichen URL vornehmen oder Hashänderungen verwenden, um das nach der URL zu ändern. Es gibt jedoch keine Möglichkeit, Änderungen vorzunehmen, ohne die gesamte Seite neu zu laden.

Die einzige Option, die ich kenne, um das zu erreichen, was Sie suchen, ist, dass Ihr Server alle URLs zu Ihrer gewünschten Basis-URL umleitet und neu schreibt und dann Ihren Pfad, Dateinamen, Parameter, Hash usw. an Ihre Client-seitiger Router/Controller. Ich muss davon abraten, weil (ohne zu viel Detail) Links von Ihrer Website auf Facebook immer http://example.com/ oder was auch immer Ihre Basis-URL ist gehen.

Meiner Meinung nach und in meiner Praxis verwende ich nicht History API und stattdessen Hash-Änderungen, weil es überall funktioniert. Es ist nicht immer schön, aber ich denke, dass Sie sich bemühen sollten, neben dem Hash eine angemessene Webserver-Antwort für URLs zu haben. Dies ist eine besonders hässliche URL von einer Website von mir: http://www.respectfulrevolution.org/road/videos/ian_barlow_finding_our_roots_forest#/road/videos/marcy_westerling_livingly_dying, aber wenn sie in einem Browser geladen wird, antwortet der Server mit dem, was Sie hier sehen: http://www.respectfulrevolution.org/road/videos/ian_barlow_finding_our_roots_forest und lädt dann die Client-Seite-Controller, was Sie hier sehen, danach: http://www.respectfulrevolution.org/#/road/videos/marcy_westering_livingly_dying , die geladen werden sollen das gleiche wie: http://www.respectfulrevolution.org/road/videos/marcy_westering_livingly_dying