with - Suivi de l'état à l'aide d'ASP.NET AJAX/ICallbackEventHandler




mvc ajax c# (4)

J'ai un problème avec le maintien de l'état dans une page ASP.NET AJAX. Version courte: J'ai besoin d'un moyen de mettre à jour la page ViewState après un callback asynchrone, pour refléter les changements d'état effectués par le serveur lors de l'appel asynchrone.

Cela semble être un problème commun, mais je vais décrire mon scénario pour aider à expliquer:

J'ai un contrôle en forme de grille qui a quelques améliorations JavaScript - à savoir, la possibilité de faire glisser et déposer des colonnes et des lignes. Lorsqu'une colonne ou une ligne est placée dans une nouvelle position, une méthode AJAX est appelée pour avertir le serveur de contrôle et déclencher un événement côté serveur correspondant ("OnColumnMoved" ou "OnRowMoved").

Les appels ASP.NET AJAX envoient par défaut la page entière en tant que requête. Ainsi, la page passe par un cycle de vie complet, viewstate est conservé et l'état du contrôle est restauré avant l'appel de la méthode RaiseCallbackEvent.

Toutefois, étant donné que l'appel AJAX ne met pas à jour la page, ViewState reflète l'état d'origine du contrôle, même après le déplacement de la colonne ou de la ligne. Ainsi, la seconde fois qu'une action côté client se produit, la requête AJAX est envoyée au serveur et la page et le contrôle sont reconstitués pour refléter le premier état du contrôle, pas l'état après le déplacement de la première colonne ou ligne.

Ce problème s'étend à de nombreuses implications. Par exemple, si nous avons une action côté client / AJAX pour ajouter un nouvel élément à la grille, puis qu'une ligne est déplacée, la grille est construite côté serveur avec un élément de moins que sur le côté client.

Et finalement, et plus sérieusement pour mon exemple spécifique, l'objet de source de données sur lequel nous agissons est stocké dans la page ViewState. Il s'agissait d'une décision de conception permettant de conserver une copie avec état des données manipulées qui peuvent être validées dans la base de données après de nombreuses manipulations ou supprimées si l'utilisateur recule. C'est très difficile à changer.

Donc, encore une fois, j'ai besoin d'un moyen pour que la page ViewState soit mise à jour sur le rappel après le lancement de la méthode AJAX.


En fait, j'ai trouvé ces deux liens que vous avez fournis, mais comme indiqué, ils décrivent simplement le problème, pas le résoudre. L'auteur de l'article de blog suggère une solution de contournement en utilisant un fournisseur ViewState différent, mais malheureusement ce n'est pas une possibilité dans ce cas ... Je dois vraiment laisser les détails de ViewState tout seul et juste accrocher à ce qui est fait hors de la boîte.


Jetez un œil à cet article de blog: Tweaking the ICallbackEventHandler et Viewstate . L'auteur semble aborder la situation que vous vivez:

Donc, lorsque vous utilisez ICallbackEventHandler, vous avez deux obstacles à surmonter pour avoir une gestion d'état mise à jour pour les rappels. Le premier est le problème de viewstate en lecture seule. L'autre enregistre en fait les modifications que l'utilisateur a apportées à la page avant de déclencher le rappel.

Voir l'article de blog pour ses suggestions sur la façon de résoudre ce problème. Jetez également un coup d'œil sur ce forum qui traite du même problème.


J'ai trouvé une solution assez élégante avec RadAjaxManager de Telerik . Cela fonctionne assez bien, essentiellement vous enregistrez chaque contrôle qui peut invoquer une publication, puis enregistrez chaque contrôle qui doit être redessiné après que la publication est effectuée de manière asynchrone. Le RadAjaxManager met à jour le DOM après la publication asynchrone et réécrit le ViewState et tous les contrôles affectés. Après avoir jeté un coup d'œil dans Reflector, il a l'air un peu kludgy sous le capot, mais il convient à mes fins.


Je ne comprends pas pourquoi vous utiliseriez un contrôle personnalisé pour cela, quand ASP.NET AJAX UpdatePanel intégré fait la même chose.

Cela ajoute simplement plus de complexité, vous donne moins de soutien et rend plus difficile le travail des autres sur votre application.





viewstate