2012-06-06 15 views
8

Estoy implementando un sitio web que establece sus URL de forma dinámica con History.js cuando las nuevas secciones se cargan en la página principal a través de ajax.Problemas con el hash History.js en Internet Explorer y el problema de pushState

Esto parece funcionar bien, pero hay un problema con la sección de hash en la url que History.js crea como una alternativa en Internet Explorer.

Éstos son ejemplos de enlaces de la página, creada usando 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; 
     }); 
    }); 
} 

El archivo .htaccess redirige cualquier URL como http://example.com/public/category_a a http://example.com, donde el javascript analiza la URL y carga la sección correspondiente a través de AJAX solicitudes en el controlador changeState.

Los controles de JavaScript para URLs tales como

http://example.com/public/category_a 

Y para URL de retorno equivalentes creados en Internet Explorer, es decir

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

que todas las obras OK - así:

En Firefox, si abro el sitio en la raíz del sitio, http://example.com, y hago clic en un enlace como se indicó anteriormente, el contenido lo anuncios (en el controlador de ChangeState), y la url es fijado por history.pushState como:

http://example.com/public/category_a 

Si hace clic en otro enlace de la URL se establece como, por ejemplo:

http://example.com/public/category_b 

en IE, si abro el sitio en la raíz del sitio y haga clic en un enlace, a lo anterior, el contenido se carga, y la url se establece con un hash como:

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

si yo cl ick en el siguiente enlace, la URL se establece como:

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

surge El problema al abrir una página en IE que se bookmarked en Firefox, y no tiene el hash en la url. Vamos a tomar el ejemplo de costumbre:

http://example.com/public/category_a 

Si abro este URL directamente en el IE, a través de un marcador o pegando la URL en la barra de direcciones del navegador, el .htaccess vuelve a dirigir con éxito, la URL se analiza bien por el js archivo y el contenido carga. Sin embargo, ahora si hago clic en el enlace category_b, la url es fijado por history.pushState a:

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

Lo que realmente quería era establecer la URL como:

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

Sin embargo, la historia. js parece tomar la totalidad de la URL anterior como la url base para los pushStates subsiguientes. He intentado establecer direcciones URL absolutas en History.pushState pero sin éxito. Como puede ver en el bloque de código anterior, tengo una instrucción pushState específica de IE. He intentado configurar esto de varias maneras.¿Cómo puedo obtener Historia pushState reconocer:

http://example.com 

como la parte de base de la URL, que la sección de hash se debe anexar a? ¿O hay una mejor manera de abordar esto que la manera que describo arriba?

+0

hola, ¿se las arregló para encontrar alguna solución al problema de cuando una página se actualiza, el navegador carga la primera URL en lugar de la actual? –

+0

¿Leyó esta pregunta ?: http://stackoverflow.com/questions/14342912/using-history-pushstate-in-ie9 Quizás pueda encontrar algunos consejos útiles – nikoskip

+0

por qué no hacer pushstate a public/category_a y "redirigir" a # para eliminar hash cuando funciona pushstate? –

Respuesta

0

AFAIK, la API de historial siempre usará la URL completa (hash sin sans) que se solicitó para la carga de la página inicial. Una vez que la página se haya cargado, puede usar la API de historial para cambiar lo que viene después de esa URL inicial o puede usar cambios hash para cambiar lo que viene después de esa URL inicial, pero no hay forma de modificarla sin volver a cargar toda la página.

La única opción que conozco para lograr lo que está buscando es hacer que su servidor redirija/reescriba todas las URL a su URL base deseada y luego pase su ruta, nombre de archivo, parámetros, hash, etc. a su enrutador/controlador del lado del cliente. Tengo que desaconsejar esto porque (sin demasiados detalles) los enlaces de su sitio web compartido en Facebook siempre irán al http://example.com/ o cualquiera que sea su URL base.

En mi opinión y en mi práctica, no uso la API de historial y en su lugar uso los cambios hash porque funciona en todas partes. No siempre es lindo, pero creo que deberías esforzarte por tener una respuesta adecuada del servidor web para las URL, además del hash. Esta es una URL particularmente fea de un sitio web mío: http://www.respectfulrevolution.org/road/videos/ian_barlow_finding_our_roots_forest#/road/videos/marcy_westerling_livingly_dying, pero cuando se carga en un navegador, el servidor responde con lo que ve aquí: http://www.respectfulrevolution.org/road/videos/ian_barlow_finding_our_roots_forest y luego el controlador del lado del cliente carga lo que ve aquí después: http://www.respectfulrevolution.org/#/road/videos/marcy_westering_livingly_dying que debería cargarse lo mismo que: http://www.respectfulrevolution.org/road/videos/marcy_westering_livingly_dying

Cuestiones relacionadas