EnableViewState e TextBox

Uma das grandes novidades do ASP.NET foi a introdução do Viewstate, o qual se encarrega de manter os estados dos controles entre os postbacks. Com isso, muitos pensam que a persistencia da propriedade Text está atrelada a propriedade EnableViewState do controle, ou seja, quando alguém não quer que a mesma seja mantida durante os postbacks, tenta definí-la como False, mas isso não é possível.

O que acontece é que o ASP.NET não usa o ViewState para isso e sim para uma outra finalidade. O segredo está na interface IPostBackDataHandler que o controle TextBox implementa. Ela contém um método chamado LoadPostData, que retorna um valor booleano indicando se o valor foi ou não alterado. É baseado neste retorno que é ou não disparado o evento TextChanged do TextBox. É passado como parametro para este método, a coleção de parametros enviados pelo post do formulário, qual internamente recupera o valor da propriedade value do respectivo controle. Podemos visualizar isso ao decompilar tal método:

protected virtual bool LoadPostData(string postDataKey, NameValueCollection postCollection)
{
      base.ValidateEvent(postDataKey);
      string text1 = this.Text;
      string text2 = postCollection[postDataKey];
      if (!this.ReadOnly && !text1.Equals(text2, StringComparison.Ordinal))
      {
            this.Text = text2;
            return true;
      }
      return false;
}

Se colocar o controle TextBox no Wacth do Visual Studio, verá que no momento do postback, o valor da propriedade Text não terá nada se a propriedade EnableViewState do controle estiver como False. Somente depois de passar pelo método LoadPostData da classe é que o valor da propriedade Text é definido/restaurado, já que faz sentido, pois o ViewState do controle está desabilitado e a propriedade Text retornará vazio, qual será diferente do valor vindo pela coleção de parametros do post do formulário. Logo, o valor da propriedade Text é mantido mesmo com a propriedade EnableViewState esteja False. Para ilustrar, veja o código decompilado desta propriedade:

public virtual string Text
{
      get
      {
            string text1 = (string) this.ViewState[“Text”];
            if (text1 != null)
            {
                  return text1;
            }
            return string.Empty;
      }
      set
      {
            this.ViewState[“Text”] = value;
      }
}

Com isso vemos o porque os valores são mantidos. Se a propriedade EnableViewState estiver como False, retornará string.Empty que é diferente do valor vindo pela coleção (postCollection). Seguindo o fluxo do método LoadPostData, veremos que a condicional if é atentida e o valor do Text mudado, ou melhor, mantido. Para finalizar, verá que o evento TextChanged SEMPRE SERÁ DISPARADO, a menos que a propriedade Text seja igual a string.Empty e, o valor armazenado no ViewState[“Text”] é somente utilizado para verificar se o evento TextChanged deve ou não ser disparado.

Server.Transfer é limitado?

Eu estou trabalhando em um projeto ASP.NET e estou criando um handler, que obviamente implementa a Interface IHttpHandler, para que processe e gere um arquivo binário para forçar o download do mesmo.

Depois que configurei o arquivo Web.Config, a requisição para arquivos com extensão “*.abc” serão agora interceptados por este handler. Mas existe um grande problema aqui, porque eu estou utilizando o método Server.Transfer, então eu não posso enviar para um dos overloads deste método uma instancia deste handler que criei ou chamar diretamente o “caminho virtual”, como “Pagina.abc”. Voce pode confirmar essa informação decompilando o método Transfer utilizando o Reflector:

[ — Suprimido — ]
else if (!(handler is Page))
{
   error = new HttpException(0x194, string.Empty);
}
[ — Suprimido — ]
if (error != null)
{
   [ — Suprimido — ]
   throw new HttpException(SR.GetString(“Error_executing_child_request_for_handler”,
      new object[] { handler.GetType().ToString() }), error);
}

Independentemente do overload do método Transfer que voce use, a mensagem de erro é a mesma: “Error executing child request for [handler | Pagina.abc].”. A razão porque eu não utilizo o método Response.Redirect é que eu preciso enviar parametros através do coleção de Context.Items por questões de segurança.

A solução temporária para isso é herdar a classe Page ao invés de implementar a interface IHttpHandler no meu handler, mas eu acredito que isso não seja lá muito elegante.