¿Cómo en ASP.NET manejas sesión y pestañas múltiples?

Question

He escrito una aplicación en ASP.net, que está diseñada para permitir al usuario agregar registros a una base de datos. La página está configurada para que cuando un usuario agregue un registro, el número de identificación del registro recién agregado se establezca en sesión, la página Respuesta. Se redirige a un "Gracias por enviar" página, luego redirige a la página original para permitir más ediciones. Los usuarios también pueden usar el botón Atrás en esta pantalla para volver a la página de adición de registros original, que les permite realizar modificaciones en los datos.

Sin embargo, descubrí que almacenar el ID en la sesión no es una solución terriblemente buena, ya que un usuario podría intentar crear dos documentos en diferentes pestañas o ventanas. También he intentado configurar la ID en un control literal, pero esto causa el problema de que cuando el usuario usa el botón Atrás, el control literal no se establece en la ID y se agregan nuevos registros en lugar de uno editado.

¿Hay algún tipo de solución para esto?

Answer 1

Pregunta tonta, ¿por qué el usuario puede usar el botón Atrás para editar los datos que acaba de aceptar en una publicación?

Si la edición de los datos publicados anteriormente es un escenario común, ¿por qué no simplemente redirigir a una página cuando se aceptan los datos que les permiten editarlos? Luego, si presiona el botón Atrás, volverían a la "limpieza" original. insertar / agregar nueva página de datos.

Esto daría los siguientes flujos Añadir- > [Publicar] - > Editar- > ..... Agregar- > [Publicar] - > Editar- > [Botón Atrás] - > Agregar- > [Publicar] - > Editar- > [Publicar] - > Editar ....

Answer 2

Recomiendo almacenar su ID en QueryString. Después de agregar el registro, redirija a su " gracias " página, que luego supongo que contiene un enlace al formulario de edición que generará con la ID en la cadena de consulta. Cuando se sigue ese enlace, la página de edición debe extraer el ID de la cadena de consulta para cargar el registro correcto para editar.

Su formulario de agregar y editar puede incluso ser la misma página, cuando se proporciona una ID en la cadena de consulta, su formulario sabe editar ese registro, de lo contrario su formulario agrega un nuevo registro.

Answer 3

¿Has intentado agregar la ID en la cadena de consulta? Luego, podría leerlo y agregarlo a la sesión según sea necesario (por ejemplo, si un usuario hace clic en el botón Atrás).

Parece que hay muchos problemas que permiten editar un objeto en una página renderizada cuando se usa el botón Atrás. ¿Sería demasiado darles un botón de edición en su lugar?

Answer 4

Los controles guardan su estado en ViewState. Si elige usar SessionState en lugar de ViewState para almacenar la información, los controles guardarán su estado en el estado de sesión y no funcionarán correctamente con varias pestañas.

Todavía no he encontrado una manera de evitar este problema mientras sigo usando SessionState. Nuestra solución fue usar el ViewState normal.

Answer 5

He intentado almacenar la ID en la cadena de consulta (que está bien para editar), pero el problema es cuando la información se almacena en la sesión para cuando usan el botón Atrás. Si el usuario hace lo siguiente:

1. El usuario crea un registro (primer registro), el ID se pasa en la cadena de consulta y se almacena temporalmente en la sesión.
2. El usuario crea otro registro (segundo registro), la ID se pasa en la cadena de consulta, almacenada temporalmente en la sesión.
3. El usuario usa el botón Atrás en el primer registro para ir a la página que no tiene la cadena de consulta.

Probablemente sea un escenario descabellado, pero es posible que suceda. La única solución que tengo es bloquear el uso del botón Atrás para volver a la página de adición, usando window.history.forward () en JavaScript. Pero esto como solución es terrible.

Answer 6

Mi pregunta para usted es ¿por qué está almacenando algo en la sesión para empezar? Si puede evitar almacenar algo en la sesión, creo que estará mejor por completo.

Answer 7

Habiendo pensado en esto, ¿suena lo siguiente como una solución decente al problema que describí anteriormente?

• Al agregar un registro por primera vez, almacene una marca de tiempo de cuándo se accedió a la página de agregar en un campo oculto.
• Esta marca de tiempo se pasa a través de la sesión cuando el usuario hace clic en guardar. Junto con la identificación.
• Si el usuario abre otra pestaña al mismo tiempo y la guarda, la marca de tiempo de la nueva página se pasará por la sesión.
• Si el usuario intenta acceder a la página de agregar el primer registro (usando el botón Atrás), el sistema busca la sesión y ve si hay una marca de tiempo y si coincide con la del campo oculto para esa página.
• Si no coincide, el usuario recibe un mensaje y se le pide que edite el registro correctamente.

¿Suena esto razonable o demasiado complejo?