Como em ASP.NET, você lida com sessão e várias abas?

Question

Eu escrevi uma aplicação em ASP.net, que é projetado para permitir que os registros de usuário Adicionar a uma base de dados. A página está configurada que, quando um usuário adiciona um registro, o número de identificação do registro recém-adicionado é definido em sessão, os Response.Redirects página a um "Obrigado por enviar" a página, então redireciona para a página original para permitir mais edições. Os usuários também podem usar o botão Voltar na tela para voltar para a página de registro adicionando original, o que lhes permite fazer edições aos dados.

No entanto, eu descobri que armazenar o ID em sessão não é um terrivelmente boa solução, como um usuário pode tentar criar dois documentos em diferentes abas ou janelas. Eu também tentei definindo o ID em um controle literal, mas isso faz com que o problema que quando o usuário usa o botão Voltar, o controle literal não está definido para o ID, e os novos registros são adicionados ao invés de um que está sendo editado.

Existe algum tipo de solução para isso?

Answer 1

Pergunta boba, por que o uso de usuário no botão voltar para editar os dados apenas aceito em um post?

Se a edição de dados postado anteriormente é um cenário comum porque não basta redirecionar para uma página quando os dados são aceites que lhes permite editá-lo. Então se a apertar o botão de volta eles estariam voltando para a inserção original "limpa" / adicionar nova página de dados.

Isso daria os seguintes fluxos Adicionar -> [Post] -> Edit -> ..... Adicionar -> [Post] -> Edit -> [botão Voltar] -> Adicionar -> [Post] -> Edit -> [Post] -> Editar ....

Answer 2

Eu recomendo armazenar seu ID no QueryString. Após o registro é adicionado, redirecionar para o seu "obrigado" a página, que, em seguida, eu estou supondo que contém um link para o formulário de edição que você vai gerar com a ID na querystring. Quando esse link é seguido, a página de edição shouild puxar o ID fora da string de consulta, a fim de carregar o registro correto para editar.

Seu add e editar formulário pode até ser a mesma página, quando um ID é fornecido na querystring, o formulário sabe para editar esse registro, caso contrário sua forma adiciona um novo registro.

Answer 3

Você já tentou adicionar o ID na querystring? Então você pode lê-lo e adicioná-lo à sessão, conforme necessário (por exemplo em um usuário clicar no botão voltar).

Parece que um monte de problemas, permitindo a edição de um objeto em uma página renderizada ao usar o botão de volta. Seria demais para dar-lhes um botão de edição em vez disso?

Answer 4

Os controles de salvar seu estado no ViewState. Se você optar por usar SessionState vez de ViewState para armazenar as informações, em seguida, os controles vai salvar seu estado no estado da sessão e não vai funcionar corretamente com várias abas.

Eu ainda não encontraram uma maneira de contornar este problema enquanto ainda estiver usando SessionState. Nossa solução foi usar o ViewState normal.

Answer 5

Eu tentei armazenar o ID na querystring (que é principalmente excelentes para edição), mas o problema é que quando a informação é armazenada na sessão para quando utilizar o botão Back. Se o usuário faz o seguinte:

1. usuário cria um registro (1 registro), o ID é repassada na querystring, e temporariamente armazenados na sessão.
2. Usuário cria um novo recorde (2º registro), o ID é repassada na querystring, temporariamente armazenados na sessão.
3. Usuário usa o botão Voltar no primeiro registro para ir para a página que não tem a querystring.

É provavelmente um cenário improvável, mas é um que pode acontecer. A única solução que eu tenho é para bloquear o uso do botão Voltar para voltar para a página de adição, usando window.history.forward () em JavaScript. Mas isso como uma solução é terrível.

Answer 6

A minha pergunta para você é porque você está armazenando qualquer coisa na sessão para começar? Se você pode evitar armazenar qualquer coisa na sessão, eu acho que você vai ser melhor fora completamente.

Answer 7

Tendo pensado sobre isso, o seguinte soa como uma solução decente para o problema que descrevi acima?

• Quando a primeira adição de um registro, armazenar um timestamp de quando a página add foi acessado em um campo escondido.
• Este timestamp é passada através de sessão quando o usuário clicar em salvar. Junto com o ID.
• Se o usuário abre outra guia ao mesmo tempo e salva, então timestamp da nova página é passado através de sessão.
• Se o usuário tenta acessar a página add do primeiro registro (usando o botão voltar), os olhares do sistema a sessão, e vê se há um timestamp, e se ele corresponde a um no campo oculto para essa página.
• Se não corresponder, em seguida, o usuário recebe um prompt, e disse para editar o registro corretamente.

Isso soa razoável, ou muito excessivamente complexa?