2009-02-20 3 views
19

Come è noto, nelle applicazioni Web XHR (ovvero AJAX) non viene creata alcuna cronologia per la tua app e facendo clic sul pulsante di aggiornamento spesso l'utente esce dalla sua attività corrente. Mi sono imbattuto in location.hash (ad esempio http://anywhere/index.html#somehashvalue) per aggirare il problema di aggiornamento (usa location.hash per informare l'app dello stato corrente e utilizzare un gestore di caricamento della pagina per reimpostare tale stato). È davvero bello e sempliceSta monitorando location.hash una soluzione per la cronologia nelle app XHR?

Questo mi ha portato a pensare all'utilizzo di location.hash per tracciare la cronologia della mia app. Non voglio utilizzare le librerie esistenti, perché utilizzano iframe ecc Quindi, ecco la mia nickel e dime: quando la pagina viene caricata applicazione comincio questo:

setInterval(
     function(){ 
      if (location.hash !== appCache.currentHash) { 
       appCache.currentHash = location.hash; 
       appCache.history.push(location.hash); 
       /* ... [load state using the hash value] ... */ 
       return true; 
      } 
      return false; 
     }, 250 
); 

(AppCache è un oggetto predefinito che contiene le variabili di applicazione) L'idea è di attivare ogni azione nell'applicazione dal valore hash. Nei browser decenti, una modifica del valore hash aggiunge una voce alla cronologia, in IE (= 7) no. In tutti i browser, la navigazione indietro o avanti verso una pagina con un altro valore hash non attiva l'aggiornamento della pagina. Ecco dove subentra la funzione intervallata. Con la funzione ogni volta che viene rilevata la modifica del valore hash (a livello di programmazione o facendo clic su Avanti o Indietro), l'app può intraprendere le azioni appropriate. L'applicazione può tenere traccia della propria cronologia e dovrei essere in grado di presentare pulsanti di cronologia nell'applicazione (specialmente per gli utenti di IE).

Per quanto ne so, funziona su browser incrociato e non ci sono costi in termini di memoria o risorse del processore. Quindi la mia domanda è: sarebbe una soluzione valida per gestire la cronologia delle app XHR? Quali sono i pro e i contro?

Aggiornamento: poiché utilizzo il mio framework homebrew, non volevo utilizzare uno dei framework esistenti. Per poter usare location.hash in IE e averlo nella sua storia, ho creato un semplice script (sì, ha bisogno di un iframe) che potrebbe esserti utile. L'ho pubblicato on my site, sentitevi liberi di usarlo/modificarlo/criticarlo.

risposta

5

Penso che avrete un momento difficile sapere se un utente è andato avanti o indietro. Dire che l'url si avvia/myapp # page1 in modo da iniziare gli stati di monitoraggio. Quindi l'utente fa qualcosa per rendere l'url/myapp # page2 Quindi l'utente fa qualcosa per rendere nuovamente url/myapp # page1. Ora la loro storia è ambigua e non saprai cosa rimuovere o meno.

I framework della cronologia utilizzano iframe per aggirare le incoerenze del browser che hai menzionato. Hai solo bisogno di usare iframe nei browser che ne hanno bisogno.

Un altro inconveniente è che gli utenti torneranno sempre per il loro pulsante indietro del browser prima di andare per il pulsante indietro personalizzato. Ho la sensazione che anche il ritardo nella lettura della cronologia ogni 250 ms sia notevole. Forse riesci a fare l'intervallo ancora più stretto, ma poi non so se questo renderà le cose peggiori.

Ho utilizzato il gestore della cronologia di yui e sebbene non funzioni perfettamente in tutti i browser (in particolare ie6), è stato utilizzato da molti utenti e sviluppatori. Anche il modello che usano è abbastanza flessibile.

+0

Ci ho pensato. Forse la cronologia del disordine è anche una questione di controllo dell'applicazione - assicurandosi che l'utente finisca dove l'app lo conduce, quindi la sua posizione è sempre chiara? – KooiInc

8

ci sono 3 numeri che tendono a farsi munged insieme dalla maggior parte delle soluzioni:

  1. pulsante Indietro
  2. bookmarkability
  3. pulsante di aggiornamento

Le soluzioni basate window.location.hash può risolvere tutti e tre per la maggior parte dei casi: il valore nello hash si associa a uno stato dell'applicazione/pagina Web, quindi un utente può premere uno di "indietro"/"avanti"/"aggiorna" e jum p allo stato ora nell'hash. Possono anche aggiungere un segnalibro perché il valore nella barra degli indirizzi è cambiato. (Si noti che è necessario un codice nascosto iframe per IE correlato all'hash che non influisce sulla cronologia del browser).

Volevo solo notare che una soluzione solo iframe può essere utilizzata senza monitoraggio window.location.hash per una soluzione molto efficace.

Google maps è un grande esempio di questo. Lo stato catturato per ogni azione dell'utente è troppo grande per essere inserito in window.location.hash (centroide della mappa, risultati della ricerca, vista satellitare o mappa, finestre informative, ecc.). Quindi salvano lo stato in un modulo incorporato in uno iframe nascosto. Per inciso, questo risolve anche il problema di "aggiornamento" [soft]. Risolvono separatamente la segnalibro tramite il pulsante "Collega a questa pagina".

Ho solo pensato che valesse la pena conoscere/separare i domini del problema a cui stai pensando.

+0

4 problemi in realtà. Ti sei perso "stato". – T9b

2

Tutta questa roba è importante per supportare l'intera gamma di browser, ma si spera che ne vada la necessità. Sia IE8 che FF3.6 hanno entrambi introdotto il supporto per onhashchange. Immagino che gli altri seguiranno l'esempio. Sarebbe una buona idea controllare la disponibilità di questa funzionalità prima di utilizzare timeout o iframe, poiché è la soluzione più bella attualmente disponibile - e funziona persino in IE!

Problemi correlati