ne me rappelle, cependant, que certains comportements attendus par la plupart des formulaires Web ASP.NET de développeurs ne fonctionneront pas sans ViewState. Le but de ViewState est de donner l'illusion que diverses propriétés de page et de contrôle persistent d'une requête à l'autre. ViewState ne contient pas toutes les propriétés du contrôle, seulement celles qui ont changé. L'idée est que ViewState conserve ces propriétés telles qu'elles étaient au moment où le formulaire a été rendu.
Un bon exemple est un événement SelectedIndexChanged
sur un menu déroulant (qui n'a pas autopostback défini). Cela fonctionne parce que ViewState conserve l'index précédent, et le formulaire publie l'index actuel, et le contrôle compare les deux afin de savoir que l'index sélectionné a changé. C'est à ce moment qu'il déclenche l'événement SelectedIndexChanged
. Sans ViewState, cet événement ne se déclenchera pas. Même pour les événements TextChanged
, etc.
En l'absence de la situation GET (que je n'ai jamais rencontrée), le gros problème avec ViewState est de l'utiliser là où ce n'est pas nécessaire. Votre contrôle de grille n'a pas besoin de conserver les valeurs précédentes de tous les contrôles dans toutes ses lignes, n'activez donc pas ViewState.
@TFD: Bien que cela arrive parfois, je ne suis pas convaincu que ce soit le cas ici. L'utilisation de formulaires avec runat = "server" en conjonction avec les actions GET (au lieu de POST) entraîne exactement le type de comportement que l'utilisateur ne souhaite pas. En quoi ma réponse n'est-elle pas pertinente? –
@TFD Jon a raison, vous voudrez peut-être vérifier les liens qu'il a publiés avant de rendre public comme ça;) – eglasius
GET est probablement inapproprié quand vous voulez vraiment viewstate - mais c'est très utile quand vous n'avez * pas besoin de viewstate. En particulier, il est beaucoup plus facile de mettre en signet une URL avec des paramètres GET que de trier l'affichage de viewstate :) –