Viewstate vs Postback

Question

J'ai un peu répondu à ma propre question je pense mais je veux m'assurer que je comprends bien. J'ai d'abord pensé que lorsqu'un utilisateur fournissait des valeurs dans un formulaire, celles-ci étaient soumises en tant que partie de Viewstate, car TextBox.Text faisait partie de viewstate. Maintenant, j'ai découvert que les valeurs fournies par l'utilisateur ne sont réellement appliquées aux contrôles qu'après l'événement OnLoad. Cela m'a troublé car je pensais que viewstate était chargé dans les contrôles avant OnLoad (ou lors de l'appel de Controls.Add()). J'ai parcouru la documentation sur la page et contrôle des cycles de vie à quelques reprises et je me rends compte maintenant qu'il y avait une étape différente pour gérer les données de publication (cette étape n'apparaissait pas dans beaucoup de documentation :(

1) Donc, les données de publication, le type de l'utilisateur dans les champs, est appliqué après l'événement OnLoad, et les données Viewstate sont appliquées juste avant l'événement OnLoad

2) Donc, tout ceci signifie que le serveur reçoit deux valeurs lors de la publication. pour une propriété TextBox.Text, celle dans Viewstate, qui est comme la "ancienne" valeur de la demande précédente, et la nouvelle valeur fournie par l'utilisateur dans le formulaire?

3) Le framework .net applique-t-il les mêmes données de publication que Viewstate, en ce sens qu'il trouve le contrôle approprié via sa propriété ID? Ceci est important car je crée des contrôles de manière dynamique et je peux même avoir des formulaires qui changent de structure au fil du temps et qui doivent réfléchir à la façon dont je gère les ID. Jusqu'à présent, je n'ai pas mis la propriété ID et tout fonctionne bien, mais les choses peuvent être plus compliquées plus tard.

4) Les données viewstate sont-elles toujours modifiées du côté client? Ou est-ce que viewstate est identique à ce qui a été envoyé par le serveur dans la requête précédente (en supposant qu'il n'y a pas de falsification)? Mon impression était que le serveur encodait toutes les propriétés de contrôle dans le viewstate, et du côté client lorsque l'utilisateur soumettait le formulaire, le champ viewstate était décodé, modifié, codé et soumis au serveur avec des modifications. J'ai supposé qu'il y avait un tas de javascript faisant tout cela pour moi. Maintenant, je pense que j'avais tout faux. Au lieu de cela il semble que le Viewstate ne change jamais du côté client, et toutes les modifications du client sont dans les données de publication de sorte que la prochaine demande le serveur charge viewstate, charge la publication et fournit un nouveau viewstate mis à jour dans la réponse suivante?

Answer 1

1) Les deux sont chargés avant que la charge
2) En gros, oui
3) ViewState est appliqué en premier, puis après les données

Pour citer Scott Mitchell (voir ci-dessous)

dynamiquement ajouté les contrôles doivent être ajoutés par programmation à la page Web à chaque visite de page. Le meilleur temps pour ajouter ces contrôles est pendant l'étape d'initialisation du cycle de vie de la page , qui se produit avant l'étape d'état d'affichage de la charge. C'est-à-dire que nous voulons que la hiérarchie de contrôle soit complète avant l'arrivée de l'état d'affichage de la charge . Pour cette raison, il est préférable de créer un gestionnaire d'événements pour l'événement Init de la classe Page dans votre classe de code-behind , et d'y ajouter vos contrôles dynamiques .

4) Sauf si vous faites quelque chose hors de la boîte, ViewState n'est jamais modifié côté client. "ViewState" est un champ de formulaire HTML et est traité côté serveur.Voici quelques images de Understanding ASP.NET View State par Scott Mitchell qui peuvent vous aider.

alt text http://i.msdn.microsoft.com/ms972976.viewstate_fig02%28en-us,MSDN.10%29.gif alt text http://i.msdn.microsoft.com/ms972976.viewstate_fig04%28en-us,MSDN.10%29.gif

Bonus lecture Matériel: http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx

Answer 2

Mon impression temps que le serveur encodé toutes les propriétés de contrôle dans le viewstate, et du côté client lorsque l'utilisateur soumis le formulaire, le champ viewstate a été décodé, modifié, codé et soumis au serveur avec des modifications.

Non, le point de la ViewState est tout simplement de préserver l'état de la page depuis le dernier événement de la page « Enregistrer l'état d'affichage », à savoir que l'événement se produit peu de temps avant que la page est rendu au client. Lorsque le client effectue des sélections dans une zone de liste déroulante ou modifie le texte d'une zone de texte, la propriété ViewState masquée, qui existe sur la page client en tant que balise HTML statique, ne modifie ni ne codage dynamiquement ces valeurs. lorsque la page a été rendue.

Ainsi, comment le nouvel état de la page est-il préservé, c'est-à-dire, comment les sélections d'utilisateur et les valeurs de zone de texte sont-elles conservées dans les contrôles ASP? Ces sélections et les valeurs de zone de texte sont capturées dans les données de retour.

A server control can indicate that it is interested in examining the posted back data by implementing the IPostBackDataHandler interface. In this stage in the page life cycle, the Page class enumerates the posted back form fields, and searches for the corresponding server control. If it finds the control, it checks to see if the control implements the IPostBackDataHandler interface. If it does, it hands off the appropriate postback data to the server control by calling the control's LoadPostData() method. The server control would then update its state based on this postback data. 

- Scott Mitchell