2009-05-15 4 views
1

EDIT 2: Eh bien, je suis allé au code. Notez ce qu'ils font ici. Ils disent load viewstate, puis retournent et définissent la propriété Text à ce qui était dans le viewstate. Une fois LoadViewState appelé, le suivi de viewstate est activé, ce qui entraîne le comportement que je vois. Je pense que ce que le code devrait dire est:Bug dans l'implémentation Label ASP.ViewState?

si (s! = Texte) {Text = s;}. Cela éliminerait complètement la question et garderait l'invariant dont ils ont besoin. Editer: De tous mes tests, cela semble affecter uniquement le contrôle Label.

/// <internalonly/> 
     /// <devdoc> 
     /// <para>Load previously saved state. 
     ///  Overridden to synchronize Text property with LiteralContent.</para> 
     /// </devdoc> 
     protected override void LoadViewState(object savedState) { 
      if (savedState != null) { 
       base.LoadViewState(savedState); 
       string s = (string)ViewState["Text"]; 
       if (s != null) 
        Text = s; 
      } 
     } 
Je pense toujours que c'est un bug.

Ceci est un site Web ASP.NET 3.5.

Tenir compte la page .aspx suivante: (html, tête, corps, etc. snipped)

<form id="form1" runat="server"> 
     <asp:Label runat="server" ID="label1"> 
      This is a lot of text. 
      This is a lot of text. 
      This is a lot of text. 
      This is a lot of text. 
      This is a lot of text. 
      This is a lot of text. 
      This is a lot of text.    
     </asp:Label> 
     <asp:Button runat="server" ID="button1" Text="Click" OnClick="button1_Click" /> 
     <script> 
      document.write(document.getElementById("__VIEWSTATE").value.length); 
     </script> 
    </form> 

La page a le code suivant derrière:

protected void button1_Click(object sender, EventArgs e) { 
     //label1.AccessKey = "a"; 
    } 

Oui, cette ligne est commenté. Venir à ça. Ainsi, lorsque vous cliquez sur le bouton, vous verrez que viewstate est de 52 octets. Même si l'étiquette contient beaucoup de texte, bien sûr, la méthode viewstate fonctionne: elle n'a pas besoin d'enregistrer les lots de texte dans viewstate car la valeur initiale de la propriété Text n'a jamais changé. D'ACCORD. Jusqu'ici tout va bien. C'est tout le comportement attendu. En fait, même si l'étiquette contenait 1 meg de texte, la taille de viewstate serait toujours de 52 octets. D'ACCORD. Maintenant, changez la méthode en

protected void button1_Click(object sender, EventArgs e) { 
     label1.AccessKey = "a"; 
    } 

Peu importe quelle propriété nous changeons. Maintenant, cliquez sur le bouton. La taille de ViewState va jusqu'à 92 octets. D'accord 40 octets pour stocker une clé d'accès d'un caractère, un peu trop si vous me demandez mais peu importe :) Maintenant, cliquez à nouveau sur le bouton. Quelle est la taille de viewstate maintenant? Doit être de 92 octets, n'est-ce pas? Non. C'est . En cliquant plus et il reste à la taille de 480 octets. Que ce passe-t-il? La modification de la propriété label a provoqué le début du stockage de l'étiquette TEXT dans viewstate. Quelle???? Collez 100K de texte dans l'étiquette et vous verrez le viewstate aller jusqu'à ~ 100K.

Est-ce un bug? Comment est-ce éventuellement comportement attendu?

+0

Ne serait pas étonnant, si c'est comme ça que ça marche. –

+0

Ça me semble être un bug. – Greg

+0

Je ne sais pas s'il s'agit d'un bogue, mais notez qu'ils ne font que définir le texte s'il était présent dans ViewState. Vérifiez l'implémentation du paramètre de propriété Text et vérifiez s'il n'a pas d'effets secondaires, ce qui peut être ce qu'ils tentent de faire. –

Répondre

0

Oui. C'est un bug dans le contrôle Label.

3

Il ne stocke pas seulement un caractère, il doit également stocker la propriété à laquelle il s'applique.

Voir http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/truly-understanding-viewstate.aspx pour plus d'informations sur comment fonctionne viewstate.

Bien que viewstate puisse se comporter différemment de ce à quoi vous vous attendez, il est peu probable qu'il y ait des bogues car viewstate est au cœur du fonctionnement d'ASP.NET.

+0

Je comprends qu'il ne stocke pas seulement le caractère. Mon commentaire snarky n'était pas le problème principal. Et oui, l'article que vous avez mentionné est exactement ce qui me conduit à croire que c'est un bug: L'article dit: « ? QU'EST-CE QUE VIEWSTATE DO 2. Les pistes des modifications à un état initial de la valeur ViewState » Mais ici, nous disons que l'état initial d'une valeur est sauvegardé lors de la modification d'un autre état initial des propriétés. – aquinas

+0

Il enregistre probablement l'état initial de chaque propriété qui n'est pas la valeur par défaut du contrôle. Dans ce cas, la valeur par défaut de la propriété text est une chaîne vide, donc elle enregistre votre texte ... – uzbones

+0

@uzbones - Selon l'article, l'état de la propriété text devrait être ce qui est défini dans le concepteur. – Greg

1

ASP.NET dev ici :) Et auteur de l'article viewstate mentionné.

En parlant comme moi et non comme MS, juste pour être clair. Oui - c'est un bug. Pour jeter un peu de lumière cependant sur pourquoi le code est en train de définir la propriété quand apparemment il n'est pas nécessaire (puisque la valeur est déjà stockée dans ViewState - pourquoi l'initialiser dans ViewState?). Si vous regardez le setter pour le texte, vous verrez qu'en plus de définir la valeur dans ViewState, il appelle Controls.Clear().Cela est dû au fait que Label prend en charge les contrôles enfants tels que «texte» ainsi qu'une chaîne littérale. S'il n'a pas défini la propriété Text dans LoadViewState, il peut rendre incorrectement les contrôles à la place du texte, ou quelque chose.

Cela devrait mieux faire face à cela - je ne suis pas sûr de savoir si le correctif que vous avez mentionné fonctionnerait dans tous les scénarios.