Question

J'ai un problème avec le maintien de l'état dans un ASP.NET page AJAX.Version courte:J'ai besoin d'une mise à jour de la page ViewState après un async rappel a été fait, afin de refléter les modifications de l'état du serveur réalisés au cours de l'appel asynchrone.

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

J'ai une grille de contrôle qui a un peu de JavaScript améliorations - à savoir, la possibilité de faire glisser et déplacer des colonnes et des lignes.Lorsqu'une colonne ou une ligne est lancée dans une nouvelle position, un AJAX méthode est invoquée pour informer le serveur de contrôle de côté et le feu d'un correspondant d'événements côté serveur ("OnColumnMoved" ou "OnRowMoved").

ASP.NET les appels AJAX, par défaut, envoyer la totalité de la page, comme le demande.De cette façon, la page passe par un cycle de vie complet, viewstate est conservé et l'état de la commande est restauré avant la RaiseCallbackEvent méthode est invoquée.

Cependant, depuis l'appel AJAX n'a pas de mise à jour de la page, le ViewState reflète l' d'origine état de la commande, même après que la colonne ou de la ligne a été déplacé.Donc la deuxième fois qu'un client du côté de l'action se produit, la requête AJAX va sur le serveur et la page et de contrôle sont construits à nouveau de retour afin de refléter la première état de la commande, pas de l'état après la première ligne ou colonne a été déplacé.

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

Et enfin, et le plus sérieusement pour mon exemple précis, le véritable objet de source de données que nous accomplissons est stockée dans la page ViewState.C'était une décision de conception pour permettre de garder une dynamique copie de la manipuler des données qui peuvent être engagés à DB après de nombreuses manipulations ou supprimé si l'utilisateur retire.C'est très difficile de changer.

Donc, encore une fois, j'ai besoin d'un moyen pour la page ViewState être mis à jour sur callback après l'AJAX méthode est déclenché.

Était-ce utile?

La solution

Si vous êtes déjà traînant le ViewState autour de toute façon, vous pourriez aussi bien utiliser un UpdatePanel.Ses publications partielles va mise à jour de la page du ViewState automatiquement.

Autres conseils

Consultez cet article de blog: Le fait de modifier les ICallbackEventHandler et Viewstate.L'auteur semble être en train de traiter la situation que vous rencontrez:

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

Voir le post de blog pour ses suggestions sur la façon de résoudre ce problème.Consultez également cette post sur le forum qui traite du même problème.

J'ai trouvé ces deux liens que vous avez fournies, mais comme l'a noté qu'ils sont tout simplement en décrivant le problème et non le résoudre.L'auteur du blog propose une solution de contournement en utilisant un autre ViewState fournisseur, mais malheureusement, ce n'est pas une possibilité dans ce cas...j'ai vraiment besoin de laisser les détails du ViewState seul et il vous suffit de brancher sur ce qui est fait out-of-the-box.

J'ai trouvé un assez élégant solution avec Telerik est RadAjaxManager.Il fonctionne très bien, essentiellement, vous inscrire à chaque contrôle qui peut invoquer une publication, puis enregistrer de contrôle qui doivent être refaits après cette publication est réalisée de manière asynchrone.Le RadAjaxManager sera mise à jour du DOM après la async publication et de réécrire le ViewState et tous les contrôles concernés.Après avoir pris un coup d'oeil dans le Réflecteur, il ressemble un peu encombrants sous le capot, mais elle convient parfaitement à mes fins.

Je ne comprends pas pourquoi vous devez utiliser une commande personnalisée pour que, lorsque le groupe builtin ASP.NET AJAX UpdatePanel fait la même chose.

Il ajoute juste plus de complexité, vous donne moins de soutien, et les rend plus difficile pour les autres de travailler sur votre application.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top