2010-08-18 4 views
6

Tengo una página ASP.NET que contiene dos div. Ambos tienen campos de búsqueda y un botón de búsqueda dentro de cada uno de ellos. Cuando llego por primera vez a esta página, Div A tiene la clase 'SearchDiv', mientras que Div B tiene 'SearchDivDisabled'. Estas clases cambian la apariencia para que el usuario sepa qué tipo de búsqueda tienen habilitado actualmente.Clase de Div no persiste cuando se usa el botón 'atrás'

Cuando se hace clic en Div B, JavaScript cambia su clase a 'SearchDiv' y cambia Div A a 'SearchDivDisabled'. Todo esto funciona como un encanto. El problema que tengo es cuando un usuario cambia a Div B, hace clic en el botón de búsqueda de Div B (que obviamente redirige a una página de resultados), y luego utiliza el botón de retroceso del navegador. Cuando vuelven a la página de búsqueda, Div A se habilita nuevamente, y Div B se desactiva, aunque usaron Div B. En el controlador de eventos del botón de búsqueda, establecí el atributo de clase de las Divs antes de redireccionar, esperando que esto se actualice la página en el servidor, de modo que cuando el usuario regrese, su última Div habilitada aún estará habilitada (independientemente de cuál se activó cuando se visitó la página por primera vez).

Creo que esto implica ViewState, pero no estoy seguro de por qué el atributo de clase no se guarda, por lo que cuando el usuario regresa a la página se restaura. ¿Hay algo que me falta aquí, o alguna forma fácil de garantizar el comportamiento que quiero? ¡Gracias!

Editar: Aquí está el botón de código de controlador de eventos:

protected void RedirectToResults(int searchEnum, string resultPage) 
{ 
    ShowContainer(searchEnum); 
    Response.Redirect(resultPage + this.webParams.getAllVariablesString(null)); 
} 

    protected void ShowContainer(int searchContainerToShow) 
    { 
    if (searchContainerToShow < 0 || searchContainerToShow > SearchContainers.Count || SearchContainers.Count == 0) 
     return; 

    //disable all search panels 
    foreach (SearchContainer container in SearchContainers.Values) 
    { 
     container.searchDiv.Attributes.Add("class", "SearchDivDisabled"); 
    } 

    //enable selected panel 
    SearchContainers[searchContainerToShow].searchDiv.Attributes.Add("class", "SearchDiv"); 
    } 

RedirectToResults() se llama desde el controlador de eventos botón real con la enumeración que representa el panel de búsqueda seleccionado y la URL de la página de resultados. SearchContainers es un diccionario que asigna un número entero a la Div de búsqueda. El código importante es la última línea, donde estoy actualizando el contenedor de búsqueda seleccionado con la clase de búsqueda 'activa', en lugar de la desactivada (que asigno a los otros divs)

Actualización adicional: He estado batallando con este problema durante los últimos días. Yo era una especie de poder conseguir el siguiente código para trabajar (en Load):

 Response.AppendHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1. 
     Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.0. 
     Response.AppendHeader("Expires", "0"); // Proxies. 

Pero esto en realidad no es una solución, como todo lo demás que consigue en caché correctamente se pierde, lo que me deja peor que cuando Yo empecé. Todo lo demás parece persistir bien, es solo la clase de div lo que me está causando dificultades.

Editar: Solo quería actualizar esto para cualquier otra persona que encuentre esto. Aunque creo que hay una solución aquí con la configuración de la caché de la página para obligar al navegador a la devolución de datos, no pude hacerlo funcionar al 100% con todos los navegadores (principalmente Firefox me estaba dando ataques, que es un error documentado). Creo que la solución de cookies funcionaría, pero creo que puede ser un poco más compleja de lo necesario para tratar de almacenar el estado de un par de div.

Lo que terminé haciendo fue vincular la clase de div al estado de su botón de radio relacionado (hay botones de opción al lado del div que permiten a los usuarios una forma más visual de habilitar los paneles de búsqueda). Me di cuenta de que estos botones de opción conservaban el valor de verificación correcto cuando se usaba el botón Atrás, por lo que podía garantizar que indicaran la habilitación del div correcto. Entonces en la carga de JavaScript, verifico qué botón de radio está habilitado, y luego ajusto las clases de los divs de búsqueda en consecuencia. Este es un truco muy grande, pero ha funcionado al 100% en todos los navegadores, y solo tomó alrededor de 10 líneas de JavaScript.

Respuesta

4

Como no está publicando hacia atrás para cambiar el estilo del div, cuando el usuario presiona el botón Atrás volverá al modo en que se publicó originalmente. La manera fácil de solucionar esto es hacer que el botón provoque una devolución de datos que alterna el estilo.

+0

Como menciono anteriormente, 'En el controlador de eventos del botón de búsqueda establezco el atributo de clase de las Divs antes de redireccionar, esperando que esto actualice la página en el servidor para que cuando el usuario regrese, su última Div habilitada siga siendo habilitado 'Así que estoy haciendo esto.Actualizaré la publicación original con el código. – Kevin

1

No creo que ViewState sea el problema aquí; puede ser algo que necesite administrarse en el código javascript del lado del cliente, ya que los estados de conmutación en el cliente no se reflejan automáticamente en el servidor ...

Lo que quiere mirar potencialmente es la gestión del historial de navegación a través de los puntos de historia cuentan: http://msdn.microsoft.com/en-us/library/cc488548.aspx

HTH.

0

Puede almacenar el id del div que está actualmente configurado en la clase 'SearchDiv' en una variable SESSION antes de hacer una redirección en el botón de búsqueda, durante la carga de la página de búsqueda obtenga el div y establezca la clase apropiada en él.
esta manera se puede seguir utilizando su Javascript para alternar las clases en los divs y sólo guardar los datos antes de volver a una página diferente y evitar la entrada innecesaria

+0

El problema con esto es que OnLoad() no se activa cuando se usa el botón Atrás. Entonces, independientemente de lo que se almacena en la sesión, no puedo cambiar nada cuando el usuario vuelve a la página de búsqueda, ya que es del lado del cliente. – Kevin

+0

Kevin, OnLoad() en la página de búsqueda no se dispara porque la página se extrae de la memoria caché. Agregar Response.Cache.SetCacheability (HttpCacheability.NoCache); en la función Page_Load de su página de búsqueda y vea si el evento se activa o no cuando hace clic en –

1

como se ha mencionado en mi respuesta anterior puede acheive todo lo que necesita el uso de variables de sesión. Como mencionó la persistencia de la selección de DIV, le pedí que la tuviera en una variable de sesión. Si desea que se mantengan otros datos del formulario, bórrelos todos en variables de sesión (asegúrese de limpiarlos cuando termine con ellos)

Esta sería la forma más fácil de cumplir con su requisito.

también está utilizando

Response.AppendHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1. 
    Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.0. 
    Response.AppendHeader("Expires", "0"); // Proxies. 

puedas simple uso

Response.Cache.SetCacheability(HttpCacheability.Private); 

en su Page_Load y acheive la misma funcionalidad

, hágamelo saber si usted tiene alguna preocupación sppecific aplicación de la presente.

+0

. Solo quería agregar un comentario a esto. Firefox es un problema con esto, ya que básicamente ignora el indicador 'Cacheability' en una página y guardará en caché lo que quiera. En IE esto tiende a funcionar, pero si quieres ser compatible con el navegador cruzado, no he encontrado una buena manera de forzar a FF a la devolución de datos cuando utilizas 'atrás' para navegar a una página. – Kevin

3

Guarde la configuración en una cookie en el lado del cliente, luego verifique la cookie mediante JavaScript al cargar la página y cambie la clase CSS. Puede que otras formas de solucionar esto no funcionen porque la página no siempre se solicita desde el servidor cuando el usuario toca el botón Back.

usando el jQuery cookie plugin

// this function will update the style of the divs based on the cookie's settings 
function updateClass(){ 
    var val = $.cookie('myCookieName'); 

    // set your div's class 
    if (!val || val=='divA') 
    { 
     $('#divA').removeClass('SearchDivDisabled'); 
     $('#divA').addClass('SearchDiv'); 
     $('#divB').removeClass('SearchDiv'); 
     $('#divB').addClass('SearchDivDisabled'); 
    }else{ 
     $('#divB').removeClass('SearchDivDisabled'); 
     $('#divB').addClass('SearchDiv'); 
     $('#divA').removeClass('SearchDiv'); 
     $('#divA').addClass('SearchDivDisabled'); 
    } 
} 

// call this passing in 'divA' or 'divB' depending on which is selected 
function updatePage(selectedDiv){ 
    $.cookie('myCookieName', selectedDiv, { path: '/', expires: 10 }); 
    updateClass(); 
} 

// change the class of the divs when the page is finished rendering 
$(document).ready(function(){updateClass();}): 
1

Esta podrían abordarse en una de dos maneras.

Si cada formulario de búsqueda publica en una URL diferente, cada URL debe establecer una variable de sesión, llamada 'LastSearchMethd', por ejemplo, para 'A' o 'B'. Si ambos publican en la misma URL, simplemente incluya un campo oculto que contenga 'A' o 'B' para cada formulario, respectivamente, y guarde el valor enviado en la variable de sesión.

De cualquier forma, debe representar el estilo de cada DIV, según el valor de la variable de sesión.

Tal como lo mencionaron otros carteles, también es necesario tener en cuenta el almacenamiento en caché.

Cuestiones relacionadas