Rastreamento de estado utilizando ASP.NET AJAX / ICallbackEventHandler

votos
9

Eu tenho um problema com a manutenção do estado em uma página ASP.NET AJAX. Versão curta: eu preciso de alguma forma de atualizar o ViewState página após um retorno de chamada assíncrona foi feito, para refletir qualquer estado altera o servidor feitas durante a chamada assíncrona.

Este parece ser um problema comum, mas vou descrever o meu cenário para ajudar a explicar:

Eu tenho um controle de grade-like que tem algumas melhorias de JavaScript - ou seja, a capacidade de arrastar e soltar colunas e linhas. Quando uma coluna ou linha é descartado em uma nova posição, um método AJAX é invocado para notificar o lado do servidor de controle e disparar um evento do lado do servidor correspondente ( OnColumnMoved ou OnRowMoved).

ASP.NET AJAX chama, por padrão, enviar a página inteira como o pedido. Dessa forma, a página passa por um ciclo de vida completo, viewstate é mantido e o estado do controle é restaurado antes que o método RaiseCallbackEvent é invocado.

No entanto, uma vez que a chamada AJAX não atualiza a página, o ViewState reflete o originais estado do controle, mesmo depois de a coluna ou linha foi movido. Assim, a segunda vez que uma ação do lado do cliente ocorre, o pedido AJAX vai para o servidor ea página e controle são construídos volta-se novamente para refletir o primeiro estado do controle, não o estado após a primeira coluna ou linha foi movido.

Este problema estende-se a muitas implicações. Por exemplo, se temos uma ação client-side / AJAX para adicionar um novo item para a rede, e em seguida, uma fileira é arrastada do lado do servidor, a grade é construída com menos um item do que no lado do cliente.

E, finalmente, e mais sério para o meu exemplo específico, o objeto de fonte de dados reais que estão agindo sobre é armazenado no ViewState página. Essa foi uma decisão de projeto para permitir manter uma cópia stateful dos dados manipulados, que pode ser comprometida com a DB depois de muitas manipulações ou descartados se o usuário desiste. Isso é muito difícil de mudar.

Então, novamente, eu preciso de uma maneira para o ViewState página para ser atualizado no retorno de chamada após o método AJAX é acionado.

Publicado 05/08/2008 em 14:52
fonte usuário
Em outras línguas...                            


5 respostas

votos
1

Se você já está embaralhando o ViewState em torno de qualquer maneira, assim como você pode usar um UpdatePanel. Seus postbacks parciais irá atualizar ViewState da página automaticamente.

Respondeu 07/08/2008 em 17:19
fonte usuário

votos
1

Confira este post: Ajustando o ICallbackEventHandler e Viewstate . O autor parece estar a resolver a própria situação que você está enfrentando:

Então, quando usando ICallbackEventHandler você tem dois obstáculos a superar para ter gerenciamento de estado actualizado para retornos de chamada. O primeiro é o problema da viewstate somente leitura. A outra é realmente registrar as mudanças que o usuário fez para a página antes de disparar a chamada de retorno.

Veja o post por suas sugestões sobre como resolver isso. Também confira este post no fórum que discute o mesmo problema também.

Respondeu 05/08/2008 em 15:25
fonte usuário

votos
0

Eu não entendo por que você iria usar um controle personalizado para que, quando o builtin ASP.NET AJAX UpdatePanel faz a mesma coisa.

Ele só adiciona mais complexidade, lhe dá menos apoio, e torna mais difícil para os outros para trabalhar em seu aplicativo.

Respondeu 08/08/2008 em 05:56
fonte usuário

votos
0

Eu encontrei uma solução bastante elegante, com RadAjaxManager de Telerik . Ele funciona muito bem, essencialmente, você se registrar cada controle que pode invocar a postagem, e em seguida, registrar cada controle que deve ser re-desenhado depois que postback é executado de forma assíncrona. O RadAjaxManager irá atualizar o DOM após o postback assíncrono e reescrever o ViewState e todos os controles afetados. Depois de dar uma espiada no refletor, que parece um pouco kludgy sob o capô, mas que se adequa meus propósitos.

Respondeu 08/08/2008 em 05:18
fonte usuário

votos
0

Na verdade, encontrei tanto desses links que você forneceu, mas como foi observado que eles são simplesmente descrevendo o problema, não resolvê-lo. O autor do post sugere uma solução alternativa usando um provedor de ViewState diferente, mas infelizmente isso não é uma possibilidade neste caso ... Eu realmente preciso deixar as particularidades do ViewState sozinho e basta ligar para o que está sendo feito sai da caixa.

Respondeu 05/08/2008 em 15:54
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more