Chroniques d'Améthyste

Cette semaine j'ai reçu un email d'une personne qui venait de lire mon article sur le viewstate[1] émaillé de plusieurs questions.
Comme il y a longtemps que je n'ai pas fais de blog je vais y répondre ici. D'autant plus que la bonne maîtrise du fonctionnement du ViewState me semble indispensable en ASP.NET.

Quand tu écris: "...Seules les données dont la propriété IsDirty est à false seront recopiées..." (partie "Créer correctement un composant dynamique"), je ne comprend pas pourquoi.
Pourquoi aller sauvegarder des propriétés qui n'ont pas été modifiées dans le code (code behind après la phase d'init et donc le marked à true) au niveau du ViewState ??? Ne souhaitons-nous pas plutôt sauvegarder ce qui a été changé dans le code afin de faire persister ces données ???

IsDirty sert à différencier deux situations.

Une propriété peut être présente dans le code d'initialisation du composant, c'est-à-dire soit alimentée au cours de son événement Init, soit déclaré dans la page ASPX comme ceci:

<asp:Button ID="Button1" runat="server" Text="Valider" />

Dans les deux cas on va trouver quelque chose de ce genre dans le code d'initialisation:

this.Button1.Text = "Valider"; (1)

Dans ce cas il est inutile de sauvegarder la valeur de la propriété Text dans le ViewState car elle est déjà dans le code généré par ASP pour initialiser la page.

Mais ce n'est pas toujours le cas. Notre code peut contenir ceci dans l'événement Page.Load:

this.Button1.Text = MaBll.MaFonction(); (2)

Si MaFonction() retourne une information rapide à obtenir et/ou non pérenne (un cours boursier!) on doit effectivement réexécuter ce code à chaque renvoi. Mais le plus souvent c'est inutile et on préfère l'enregistrer dans le ViewState pour le recharger automatiquement (on n'oublie pas d'implémenter la règle d'alimentation dans ce cas!).

Si vous comparez (1) et (2), vous constatez qu'il s'agit du même code, mais dans deux situations distinctes. IsDirty permet de les distinguer et dire à ASP.NET si on doit ou non sérialiser l'information dans le ViewState.
Voici donc ma compréhension du mécanisme.

Quand tu écris "...Simplement le fait que les composants qui implémentent IPostBackEventHandler, comme les TextBox, gèrent eux même leur état..." (partie "Persistance d'un Label"), je suis personnellement et actuellement (car j'ai peut-être pas bien compris) à moitié d'accord. En effet, le TextBox n'est persistant qu'au niveau de la propriété Text uniquement.

En effet, si je prend le TextBox suivant:

<asp:TextBox ID="txtBox1" EnableViewState="false" runat="server" />

Et que dans le page_load, je fais:
if (!this.IsPostBack)
{
txtBox1.ToolTip = "Def";
txtBox1.Text = "test";
}
La propriété Text sera bien persistante mais pas la propriété ToolTip. Ceci doit être du au fait que le POST ne "poste" que la valeur du champ  input>.

Le code standard pour créer une propriété personnalisée qui persiste sa valeur dans le viewstate est le suivant:

#region MyProperty
/// <summary>
/// (Description)
/// </summary>
[Category("Data"), Description("(Description)")]
public String MyProperty
{
    [DebuggerStepThrough]
    get
    {
        if (this.ViewState["MyProperty"] == null)
        {
            // valeur par défaut
            return default(String);
        }
        return (String)this.ViewState["MyProperty"];
    }

    [DebuggerStepThrough]
    set
    {
        this.ViewState["MyProperty"] = value;
    }
}
#endregion

(Notez la présence des commentaires, je suis un intégriste religieux la dessus!).

Je suis certain que vous comprendrez sans difficultés comment ça marche.
Si vous décompilez la classe TextBox vous verrez un code similaire pour sa propriété Text. Si vous faites de même pour ToolTip (hérité de WebControl), vous trouvez aussi la même chose!

De fait la persistance de ToolTip est active, comme celle de Text. Chez moi le code fonctionne comme prévu. Mais avec VS2008. Peut être que cela à changé par rapport à des versions plus anciennes de ASP.NET.

Depuis la rédaction de cet article, j'ai appris des choses que j'ignorai au sujet des coulisses du mécanisme de persistance qui ne doit rien à ASP.NET, mais est natif à HTML. J'ai expliqué cela dans un autre blog que je vous encourage à lire[2] également.

Je vous y encourage même vivement, car par expérience il m'aurait évité de m'arracher les cheveux sur des composants dynamiques qui ne se réinitialisent pas bien sur pas mal de projets alors que la solution tenait en une seule ligne!

Bibliographie

[1] http://www.dotnetguru.org/articles/dossiers/viewstate/viewstate.htm
[2] http://www.dotnetguru2.org/amethyste/index.php?p=785&more=1&c=1&tb=1&pb=1