2012-06-06 9 views
8

Sto implementando un sito Web che imposta gli URL in modo dinamico utilizzando History.js quando nuove sezioni vengono caricate nella pagina principale tramite ajax.Problemi di hash di History.js in Internet Explorer e problema di pushState

Questo sembra funzionare bene ma c'è un problema con la sezione di hash nell'URL che History.js crea come fallback in Internet Explorer.

Ecco alcuni esempi di link sulla pagina, creato utilizzando 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; 
     }); 
    }); 
} 

Il file .htaccess reindirizza qualsiasi URL come http://example.com/public/category_a a http://example.com, dove il javascript analizza l'URL e carica la sezione appropriata tramite la tecnologia AJAX richieste nel gestore di changeState.

I controlli javascript per URL come

http://example.com/public/category_a 

E per gli URL di fallback equivalenti creati in Internet Explorer, ovvero

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

che tutte le opere OK - così:

In Firefox, se apro il sito alla radice del sito, http://example.com, e clicco su un collegamento come sopra, il contenuto lo annunci (nel gestore changeState), e l'URL è impostato per History.pushState come:

http://example.com/public/category_a 

Se poi clicco su un altro link URL è impostato come, ad esempio:

http://example.com/public/category_b 

in IE, se apro il sito alla radice del sito, e fare clic su un link, di cui al precedente, i carichi di contenuti, e l'url è impostato con un hash come:

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

Se dunque io cl ick sul link seguente, l'url è impostato come:

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

Il problema sorge quando apro una pagina in Internet Explorer che è stata segnalibro in Firefox, e non ha l'hash nell'URL. Prendiamo il nostro solito esempio:

http://example.com/public/category_a 

Se apro questo URL direttamente in IE, tramite un segnalibro o incollando l'URL nella barra degli indirizzi del browser, il file .htaccess reindirizza con successo, l'URL viene analizzato OK dai js file e il contenuto viene caricato. Tuttavia, ora se clicco sul link category_b, l'url è impostato per History.pushState a:

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

Quello che volevo era quello di impostare l'URL come:

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

Tuttavia, la storia. js sembra prendere l'intero URL precedente come url di base per i successivi pushState. Ho provato a impostare URL assoluti in History.pushState ma senza successo. Come puoi vedere nel blocco di codice sopra, ho una dichiarazione pushState specifica per IE. Ho provato a configurarlo in vari modi.Come posso ottenere Storia pushState a riconoscere:

http://example.com 

come la parte di base del URL, che la sezione di hash deve essere aggiunto a? O c'è un modo migliore per avvicinarsi a questo rispetto al modo in cui descrivo sopra?

+0

ciao, sei riuscito a trovare qualche soluzione al problema di quando una pagina viene aggiornata, il browser carica il primo url invece di quello attuale ?? –

+0

Hai letto questo quesiton ?: http://stackoverflow.com/questions/14342912/using-history-pushstate-in-ie9 Forse puoi trovare alcuni suggerimenti utili – nikoskip

+0

perché non fare pushstate a public/category_a e "reindirizzare" a # per rimuovere hash quando funziona lo stato di pushstate? –

risposta

0

AFAIK, la storia api utilizzerà sempre l'intero URL (sans hash) richiesto per il caricamento iniziale della pagina. Una volta caricata la pagina, puoi utilizzare l'API della cronologia per modificare ciò che viene dopo quell'URL iniziale oppure puoi utilizzare le modifiche hash per modificare ciò che viene dopo quell'URL iniziale, ma non c'è modo di modificarlo senza ricaricare l'intera pagina.

L'unica opzione che conosco per ottenere ciò che stai cercando è che il tuo server reindirizzi/riscrivi tutti gli URL nell'URL di base desiderato e poi passi il tuo percorso, nome file, parametri, hash, ecc. router/controller lato client. Devo sconsigliarlo perché (senza troppi dettagli) i collegamenti dal tuo sito web condiviso su Facebook andranno sempre a http://example.com/ o qualunque sia l'URL di base.

Secondo me e nella mia pratica, non utilizzo la storia API e invece utilizzo le modifiche all'hash perché funziona ovunque. Non è sempre bello da fare, ma penso che dovresti sforzarti di avere una risposta adeguata del web server per gli URL oltre all'hash. Questo è un URL particolarmente brutto da un mio sito: http://www.respectfulrevolution.org/road/videos/ian_barlow_finding_our_roots_forest#/road/videos/marcy_westerling_livingly_dying, ma quando viene caricato in un browser, il server risponde con quello che vedi qui: http://www.respectfulrevolution.org/road/videos/ian_barlow_finding_our_roots_forest e poi il controller lato client carica ciò che vedi qui dopo: http://www.respectfulrevolution.org/#/road/videos/marcy_westering_livingly_dying che dovrebbe caricare lo stesso di: http://www.respectfulrevolution.org/road/videos/marcy_westering_livingly_dying