asp.net - route - forms asp net core
Estado de seguimiento utilizando ASP.NET AJAX/ICallbackEventHandler (5)
De hecho, encontré ambos enlaces que me brindó, pero como se señaló, simplemente están describiendo el problema, no resolviéndolo. El autor de la publicación de blog sugiere una solución mediante el uso de un proveedor de ViewState diferente, pero desafortunadamente esa no es una posibilidad en este caso ... Realmente necesito dejar los detalles del ViewState solo y simplemente aferrarme a lo que se está haciendo fuera de la caja.
Tengo un problema con el mantenimiento del estado en una página ASP.NET AJAX. Versión corta: necesito alguna forma de actualizar la página ViewState después de que se haya realizado una devolución de llamada asíncrona, para reflejar cualquier cambio de estado que haya realizado el servidor durante la llamada asincrónica.
Este parece ser un problema común, pero describiré mi escenario para ayudar a explicar:
Tengo un control tipo cuadrícula que tiene algunas mejoras de JavaScript, es decir, la capacidad de arrastrar y soltar columnas y filas. Cuando una columna o fila se coloca en una nueva posición, se invoca un método AJAX para notificar al lado del servidor de control y desencadenar un evento del lado del servidor correspondiente ("OnColumnMoved" o "OnRowMoved").
Las llamadas ASP.NET AJAX, por defecto, envían toda la página como solicitud. De esta forma, la página pasa por un ciclo de vida completo, viewstate se conserva y el estado del control se restablece antes de que se invoque el método RaiseCallbackEvent.
Sin embargo, dado que la llamada AJAX no actualiza la página, ViewState refleja el estado original del control, incluso después de mover la columna o fila. Por lo tanto, la segunda vez que ocurre una acción del lado del cliente, la solicitud AJAX va al servidor y la página y el control vuelven a crearse para reflejar el primer estado del control, no el estado después de mover la primera columna o fila.
Este problema se extiende a muchas implicaciones. Por ejemplo, si tenemos una acción AJAX / del lado del cliente para agregar un nuevo elemento a la grilla, y luego se arrastra una fila, la grilla se construye en el lado del servidor con un elemento menos que en el lado del cliente.
Y, por último y más en serio para mi ejemplo específico, el objeto de fuente de datos real sobre el que estamos actuando está almacenado en la página ViewState. Esa fue una decisión de diseño para permitir mantener una copia con estado de los datos manipulados que pueden ser comprometidos con DB después de muchas manipulaciones o descartados si el usuario se retracta. Eso es muy difícil de cambiar.
Así que, de nuevo, necesito una forma para que la página ViewState se actualice en la devolución de llamada después de que se active el método AJAX.
Echa un vistazo a esta publicación en el blog: Afinando el ICallbackEventHandler y Viewstate . El autor parece estar abordando la situación que estás experimentando:
Por lo tanto, al usar ICallbackEventHandler tiene dos obstáculos que superar para tener una administración de estado actualizada para las devoluciones de llamadas. Primero está el problema del viewstate de solo lectura. El otro es en realidad registrar los cambios que el usuario ha realizado en la página antes de activar la devolución de llamada.
Consulte la publicación del blog para conocer sus sugerencias sobre cómo solucionar esto. También echa un vistazo a esta publicación en el foro que también analiza el mismo problema.
Si ya está barajando el ViewState de todos modos, también podría usar un UpdatePanel. Sus devoluciones parciales actualizarán el ViewState de la página automáticamente.
Encontré una solución bastante elegante con RadAjaxManager de Telerik . Funciona bastante bien, esencialmente registras cada control que podría invocar una devolución de datos, y luego registras cada control que se debe volver a dibujar después de que la devolución de datos se realiza de forma asincrónica. El RadAjaxManager actualizará el DOM después de la devolución de datos asincrónica y reescribirá el ViewState y todos los controles afectados. Después de echar un vistazo en Reflector, parece un poco kludgy debajo del capó, pero se adapta a mis propósitos.
No entiendo por qué usaría un control personalizado para eso, cuando el UpdatePanel ASP.NET AJAX incorporado hace lo mismo.
Simplemente agrega más complejidad, le da menos soporte y hace que sea más difícil para otros trabajar en su aplicación.