2009-02-20 10 views
19

Como es bien sabido, en las aplicaciones web XHR (también conocido como AJAX) no se construye ningún historial para su aplicación y al hacer clic en el botón de actualización a menudo se mueve al usuario fuera de su actividad actual. Me encontré con location.hash (por ejemplo, http://anywhere/index.html#somehashvalue) para eludir el problema de actualización (use location.hash para informar a su aplicación de su estado actual y use un controlador de carga de página para restablecer ese estado). Es realmente agradable y simple.Está monitoreando location.hash una solución para el historial en las aplicaciones XHR?

Esto me llevó a pensar en usar location.hash para rastrear el historial de mi aplicación. No quiero usar las bibliotecas existentes, ya que utilizan marcos flotantes, etc Así que aquí está mi níquel y dime: cuando se carga la página de aplicaciones que comienzan este:

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 es un objeto predefinido que contiene variables de aplicación) La idea es activar cada acción en la aplicación desde el valor hash. En navegadores decentes, un cambio de valor hash agrega una entrada al historial, en IE (< = 7) no es así. En todos los navegadores, navegar hacia atrás o hacia adelante a una página con otro valor hash no desencadena una actualización de página. Ahí es donde la función intervalled toma el control. Con la función cada vez que se detecta el cambio del valor hash (mediante programación, o haciendo clic atrás o adelante), la aplicación puede tomar las medidas adecuadas. La aplicación puede realizar un seguimiento de su propio historial y debería poder presentar los botones de historial en la aplicación (especialmente para usuarios de IE).

Por lo que yo sé, esto funciona con el navegador cruzado y no hay ningún costo en términos de recursos de memoria o procesador. Entonces mi pregunta es: ¿sería esta una solución viable para administrar la historia en XHR-apps? ¿Cuáles son los pros y los contras?

Actualización: porque uso mi framework homebrew, no quería usar uno de los frameworks existentes. Para poder usar location.hash en IE y tenerlo en su historial también, creé un script simple (sí, necesita un iframe) que puede ser útil para usted. Lo publiqué on my site, no dude en usar/modificar/criticarlo.

Respuesta

5

Creo que le resultará difícil saber si un usuario avanzó o retrocedió. Digamos que la URL inicia/myapp # page1 para que pueda comenzar a rastrear estados. Luego, el usuario hace algo para crear la url/myapp # page2 Luego, el usuario hace algo para que la url/myapp # page1 vuelva a estar disponible. Ahora su historia es ambigua y no sabrá qué eliminar o no.

Los marcos de historial usan iframes para evitar las incoherencias del navegador que usted mencionó. Solo necesita usar iframes en los navegadores que los necesitan.

Otra desventaja es que los usuarios siempre irán por el botón de retroceso de su navegador antes de ir a su botón de retroceso personalizado. Tengo la sensación de que el retraso en la lectura de la historia cada 250 ms también será notable. Tal vez puedas hacer el intervalo aún más apretado, pero entonces no sé si eso hará que las cosas funcionen mal.

He usado el administrador de historial de yui, y aunque no funciona perfectamente todo el tiempo en todos los navegadores (especialmente ie6), ha sido utilizado por muchos usuarios y desarrolladores. El patrón que usan es bastante flexible también.

+0

Pensé en eso. ¿Quizás la historia abarrotada también es una cuestión de control de aplicaciones, asegurándose de que el usuario termine donde lo lleva la aplicación, por lo que su posición es siempre clara? – KooiInc

8

Hay 3 temas que tienden a obtener munged juntos por la mayoría de las soluciones:

  1. botón de retroceso
  2. bookmarkability
  3. botón de actualización

Los window.location.hash soluciones basadas puede resolver los tres para la mayoría de los casos: el valor en el hash se asigna a un estado de la aplicación/página web, por lo que un usuario puede presionar uno de "volver"/"reenviar"/"actualizar" y p al estado ahora en el hash. También pueden marcar como favorito porque el valor en la barra de direcciones ha cambiado. (Tenga en cuenta que se necesita un iframe oculto para IE relacionado con el hash que no afecta el historial del navegador).

Solo quería señalar que una solución de iframe solo se puede utilizar sin monitorizar window.location.hash para una solución muy efectiva también.

Google maps es un gran ejemplo de esto. El estado capturado para cada acción del usuario es demasiado grande para colocarlo en window.location.hash (centroide del mapa, resultados de búsqueda, satélite frente a vista de mapa, ventanas de información, etc.). Así que guardan el estado en una forma incrustada en un iframe oculto. Por cierto, esto resuelve el problema de "actualización" [suave] también. Resuelven la marcabilidad por separado a través del botón "Enlazar a esta página".

Solo pensé que sería una experiencia saber/separar los dominios problemáticos en los que estás pensando.

+0

4 problemas en realidad. Te perdiste "estado". – T9b

2

Todo eso es importante para admitir toda la gama de navegadores, pero con suerte la necesidad desaparecerá. IE8 y FF3.6 ambos presentaron soporte para onhashchange. Me imagino que otros seguirán el ejemplo. Sería una buena idea verificar la disponibilidad de esta funcionalidad antes de usar tiempos de espera o iframes, ya que es realmente la mejor solución actualmente disponible: ¡e incluso funciona en IE!

Cuestiones relacionadas