Veja o vídeo aqui.

Como podemos remover o ViewState completamente e ainda permitir que os componentes mantenham seu estado? Simples, podemos gravar o ViewState em algum outro local – um banco de dados, ou talvez em algum outro recurso de persistência que o ASP.Net nos disponibilize. Neste caso, vamos utilizar o Cache.

Páginas ASP.Net possuem dois métodos que permitem o programador redirecionar o conteúdo que está no ViewState para outro lugar. Esses métodos são SavePageStateToPersistenceMedium e LoadPageStateFromPersistenceMedium. Partindo desses métodos, é bem simples imaginar o que deve ser feito: no primeiro salvamos os dados no Cache, e no segundo buscamos esses dados. Precisamos de uma chave única para os ViewStates de usuários diferentes e páginas diferentes não sejam misturados. Vamos utilizar uma GUID. A declaração desses métodos dentro da sua página fica assim:

strict protected
  function LoadPageStateFromPersistenceMedium: System.Object; override;
  procedure SavePageStateToPersistenceMedium(ViewState:
		System.Object); override;

E a implementação deles, assim:

const
  HiddenFieldViewState = 'ChaveViewState';

procedure TWebForm1.SavePageStateToPersistenceMedium(ViewState: TObject);
var
  ChaveViewState: string;
begin
  ChaveViewState := Guid.NewGuid.ToString;
  Cache.Add(ChaveViewState, ViewState, nil,
    System.DateTime.Now.AddMinutes(Session.Timeout),
	Cache.NoSlidingExpiration,
    	CacheItemPriority.Default, nil);
  RegisterHiddenField(HiddenFieldViewState, ChaveViewState);
end;

function TWebForm1.LoadPageStateFromPersistenceMedium: System.Object;
var
  ChaveViewState: string;
begin
  ChaveViewState := Request.Form[HiddenFieldViewState];
  Result := Cache[ChaveViewState];
end;

Veja como geramos um novo GUID, e salvamos ele em um campo oculto no formulário para podermos recuperar o ViewState depois.

Esta alteração tem uma vantagem óbvia: páginas ficam menores e mais rápidas de serem baixadas pelos visitantes da sua página. Algumas desvantagens aparecem, uma delas sendo o fato que toda essa informação está sendo gravada  na memória do servidor pelo tempo determinado pelo timeout da sessão. Por esse motivo, a informação que antes estava no ViewState e antes era válida mesmo que o usuário mantivesse a página aberta por dias e dias, e só então enviasse o formulário, agora tem uma data de expiração determinada.

O cache não é o único lugar para se manter o ViewState, mas o mais prático por ser esvaziado automaticamente após determinado tempo mesmo que o visitante feche o browser e nunca mais visite sua página. É fácil adaptar esse método para salvar informações em um banco de dados ou algum mecanismo parecido.

Já comentei que, para evitar que o ViewState seja alterado por alguém que queira tentar explorar alguma vulnerabilidade na sua aplicação web, é gerado um hash do seu conteúdo e, no postback, esse hash é conferido para garantir a integridade dos dados. Se esse valor não está correto, o ASP.Net gera uma exceção e não permite o carregamento da página:

Esse hash não é gerado de uma forma igual em todos os servidores, é claro. Caso fosse, seria bastante simples alterar os dados e gerar um novo hash para driblar esse mecanismo de segurança. Para gerá-lo, é usada uma chave única em cada máquina, baseada no endereço MAC da placa de rede desse servidor.

O problema aparece quando estamos utilizando uma aplicacão ASP.Net em um ambiente com balanceamento de carga. Cada servidor vai ter uma chave diferente, e se uma página for gerada em um servidor e no postback cair em outro, vai ser gerada uma bela exceção para seu usário.

É possível desabilitar a geração desse hash, adicionando a seguinte entrada no web.config da sua aplicação:

<system.web>
  <pages enableViewStateMac="false" />
</system.web>

Isso desabilita a segurança, e geralmente não é uma boa idéia. A solução real é simples, e é bom conhecê-la antes que seus usuários comecem a ter problemas: basta gerar uma chave única, e utilizá-la em todos os servidores da sua web farm.

Para gerar uma chave, existem algumas ferramentas disponíveis. Uma delas é o <machineKey> Generator, uma aplicação online onde basta configurar alguns parâmetros, gerar a chave e colar o resultado dentro do nó <system.web> do web.config de sua aplicação, e replicá-lo em todas os seus servidores web. Também é possível alterar o machine.config de cada máquina para evitar incluir essa informação em cada aplicação.

A classe que representa uma página, no ASP.Net, possui uma propriedade ViewState. Ela, é, basicamente, uma coleção de items armazenados por Nome/Valor. Podemos guardar qualquer informação nesse campo, e obtê-la novamente a qualquer momento, desde que seja na mesma página.

Para servir como exemplo, vamos criar uma aplicação com um TextBox, um botão e um Label. O objetivo é, ao clicar no botão, ler um número do TextBox, e acumular esse valor, mostrando a soma total no Label. O acumulador começa em zero.

Podemos implementar esse problema assim:

procedure TWebForm1.Button1_Click(sender: System.Object; e: System.EventArgs);
const
  ChaveTotal = 'Total';
var
  Valor: Integer;
  Total: Integer;
begin
  Valor := Int32.Parse(TextBox1.Text);
  if Assigned(ViewState[ChaveTotal]) then
    Total := Integer(ViewState[ChaveTotal])
  else
    Total := 0;
  Total := Total + Valor;
  ViewState[ChaveTotal] := System.Object(Total);
  Label1.Text := Total.ToString;
end;

Dessa forma, estamos guardando um valor que sobrevive atualizações de página em um campo oculto dentro dela. O valor não é compartilhado por outros usuários que estejam acessando o site ou por outras páginas que esse mesmo usuário possa visitar. Quando o browser for fechado, o valor é perdido. E, como já vimos anteriormente, é fácil decodificar o viewstate (apesar de ser mais difil alterá-lo), portanto não armazene informações confidenciais dessa maneira.

ViewState é uma string armazenada em um campo oculto, dentro do HTML gerado para a sua página. Se você criar uma nova aplicação ASP.Net, sem nada, rodar, e olhar o código fonte da página vazia que foi gerada, vai encontrar algo parecido com isso:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
  <head>
    <title></title>
  </head>

  <body>
     <form name="_ctl0" method="post" action="WebForm1.aspx" id="_ctl0">
<input type="hidden" name="__VIEWSTATE" value="dDwtNjU0MzcyMTk1Ozs++0nkj9wYEIHhJubPoNiG5UGjjaI=" />

     </form>
  </body>
</html>

É fácil de ver o viewstate nesse código fonte. Ele é um conjunto de dados sobre a página e seus componentes, concatenado com um hash gerado no servidor para evitar ataques onde alguma pessoa maliciosa altere o conteúdo dessa string e faça um postback para o seu servidor. Essa string está em Base64, e é simples decodificar, como por exemplo usando o ViewState Decoder. Vamos ver o que o viewstate da nossa página vazia possui:

<?xml version="1.0" encoding="utf-16"?>
<viewstate>
  <Triplet>
    <String>-654372195</String>
  </Triplet>
</viewstate>

Não existe nada de interessante ainda, apenas o hash da página, que evita alterações não permitidas.

Cada componente colocado em uma página ASP.Net vai salvar seu estado no ViewState, para que cada vez que acontecer um postback esse componente possa voltar a ser exibido exatamente como estava antes, sem precisar fazer nova inicialização ou trazer os dados novamente do banco de dados, e assim por diante. Isso é prático, mas pode deixar o ViewState incrivelmente grande e aumentar bastante o tamanho da sua página – e o tempo de carregamento por consequência.

Vamos fazer um teste para ver como isso funciona: coloque um DropDownList, um botão e um ListBox em uma nova página ASP.Net. Coloque o seguinte código no PageLoad para popular o DropDownList com algumas opções:

procedure TWebForm1.Page_Load(sender: System.Object; e: System.EventArgs);
begin
  if not IsPostBack then
  begin
    DropDownList1.Items.Add('Um');
    DropDownList1.Items.Add('Dois');
    DropDownList1.Items.Add('Três');
  end;
end;

Escreva também o código apropriado no botão para adicionar no ListBox o item selecionado do DropDownList. Rode a aplicação, selecione alguns items diferentes e aperte botão para ir adicionando esses items. Repare como o DropDownList mantém os items mesmo não sendo preenchido toda vez, e como o ViewState vai aumentando o tamanho cada vez que você adiciona um item novo. Utilize a ferramenta que mostrei anteriormente para ver o que está dentro dele cada vez que você pressiona o botão.

Para ver o que o ViewState faz de verdade, vá até o DropDownList e altere a opção EnableViewState para False. Rode a aplicação de novo e perceba como após a primeira atualização de página, os items que tinham sidos adicionados no DropDownList não estão mais lá. Podemos alterar nosso código que carrega os items no PageLoad para fazer o carregamento toda vez, e não só quando não for Postback. Tirando o if, os items são carregados a cada requisição, diminuindo o tamanho do viewstate. Em uma aplicação mais realista, é bem possível que esses dados estivessem vindo do banco de dados, então estariamos fazendo bem mais consultas, o que geralmente é prejudicial à performance e à carga do servidor. Nesse caso deve se usar o bom senso e considerar o que é mais importante para cada situação: não há uma regra padrão.

Outro experimento interessante para entender o funcionamento do ViewState é desligar o ViewState da ListBox, e rodar o exemplo novamente. Acho que neste ponto você já consegue imaginar como a aplicação vai se comportar, e entender o motivo. O último teste a fazer é trocar a DropDownList por um TextBox, e rodar a aplicação com o ViewState da TextBox ligado e desligado. Surpreso por ver o conteúdo da TextBox sendo mantido mesmo com o ViewState desligado? É porque o conteúdo de campos em formulários é submetido normalmente a cada requisição, sem precisar de espaço extra no ViewState para isso.

O ViewState não serve apenas para guardar o estado de controles que estão na página – você pode guardar os dados da sua aplicação nesse campo oculto, se eles forem aplicáveis só para uma página. Vou explicar como fazer isso no próximo artigo.

Web é Stateless. Isso quer dizer que não guarda estado. É como a garota do “Como se fosse a primeira vez“: cada requisição de página é a primeira – ela pode ter acabado de servir uma página com um monte de conteúdo dinâmico para você, mas assim que a requisição acaba, ela esquece de tudo e começa uma nova sem lembrar de nada do que aconteceu anteriormente.

ASP.Net tem diversos truques para contornar isso. Afinal, é essencial manter estado em uma aplicação web. Você faz login em uma página, ela tem que lembrar quem é você por algum tempo. Você coloca ítens em carrinhos de compras, seleciona objetos para trabalhar depois, faz buscas e navega pelos resultados, enfim, aplicações web precisam de lembretes do que aconteceu no passado para poder fazer alguma coisa diferente em cada requisição.

Para entender o tempo de vida da página ASP.Net, vamos primeiro assumir que esses lembretes existem, e funcionam, salvando o estado de todos os controles que estão na página. Explico como funcionam depois em uma próxima ocasião. Tendo isso, voltamos ao ponto inicial: na primeira requisição uma página é criada, seu evento OnInit() é chamado, depois o Page_Load(), é devolvida para o browser do usuário, e a página é destruída. Lá ele navega, preenche formulários, até que aperta um botão ou faz alguma uma ação quere requer uma nova requisição ao servidor para executar algum código que você escrever. Essa requisição é chamada de PostBack.

Ao receber um PostBack, a sequência de ações é parecida: é criada uma página, o OnInit() é chamado, e então o mecanismo de lembretes é acionado carregando os valores que o usuário digitou nos componentes apropriados, e voltando o estado que a página tinha na requisição anterior. Então o Page_Load() é chamado rodando novamente qualquer código de inicialização que você tenha alí. Finalmente, o evento do botão pressionado (ou de qualquer outra ação que o usuário tenha feito) é executado, o conteúdo da página é devolvido para o browser do usuário, e a página é destruída. Entendendo isso, é fácil de ver como um código assim está errado:

procedure TWebForm1.Page_Load(sender: System.Object; e: System.EventArgs);
begin
  TextBox1.Text := 'Digite aqui';
end;

procedure TWebForm1.Button1_Click(sender: System.Object; e: System.EventArgs);
begin
  ListBox1.Items.Add(TextBox1.Text);
end;

O Page_Load é executado toda vez que a página é atualizada. Ao apertar o botão, ele é executado antes do Click do botão. Resultado: vários ‘Digite aqui’ inseridos no ListBox, e nada do que o usuário digitou foi aproveitado. A solução é bem simples. A página possui uma propriedade que diz se é o carregamento inicial ou se um PostBack está sendo processado, permitindo que assim seja feita qualquer tipo de inicialização:

procedure TWebForm1.Page_Load(sender: System.Object; e: System.EventArgs);
begin
  if not IsPostBack then
    TextBox1.Text := 'Digite aqui';
end;

Sabendo que nenhuma variável interna do formulário web é guardada entre requisições, e entendendo que a cada passo a página é criada e inicializada novamente, fica bem mais fácil entender e evitar erros simples no inicio do desenvolvimento com ASP.Net.

Um próximo passo é entender como o ASP.Net guarda estado dos componentes da página e outras informações entre requisições, para que possamos usar isso a nosso favor. Até a próxima!

Para desenvolvimento web, ASP.Net é minha escolha. Um framework bastante completo, fácil e poderoso. Bem familiar pra quem programa em Delphi, sendo possível até a utilização de parte de seu código já escrito em Delphi, já testado e aprovado, e seus conhecimentos existentes.

Ao contrário do que muita gente pensa, ASP.Net não tem nada a ver com ASP (apenas parte da sigla, mesmo).

Pra quem nunca trabalhou com ASP.Net, seguem algumas dicas para começar, no Delphi 2006:

Você pode utilizar no desenvolvimento, como servidor web, tanto o IIS como o Cassini, um servidor web open-source escrito em C#. Pessoalmente, utilizo o IIS: minha aplicação tem o mesmo comportamento de que terá em produção, e é tão fácil de usar quanto o Cassini. O IIS vem no Windows XP Pro, mas não instalado por padrão – é só ir no painel de controle e instalar. Se você instalar o IIS depois de ter instalado o framework do .Net, terá que registrar o ASP.Net no IIS manualmente. É fácil: vá no prompt de comando e digite: aspnet_regiis -i (confirme que esteja rodando esse utilitário a partir da instalação do framework 1.1).

Ao criar uma nova aplicação web, depois de escolher seu servidor web e o local que vai salvá-la (não precisa necessariamente ser em c:\inetpub\wwwroot, pode ficar junto com seus outros projetos), você tem uma WebForm1 pronta para ser usada. Se quiser renomeá-la, o IIS geralmente reconhece Default.aspx como arquivo padrão se informado só o diretório (como o index.html). Um formulário web em ASP.Net tem duas partes: o .aspx e o .pas. Essa separação é chamada de “Code Behind”.

Tecnicamente, cada arquivo tem uma classe completa, que se ligam por herança. No aspx fica o layout da sua página, num quase-html, e no .pas fica a implementação do seu código, os eventos e outras funções. Você pode encontrar exemplos de aplicações ASP.Net em C# ou VB.Net por aí onde o código é misturado com o html dentro do aspx, mais ou menos como era no ASP antigamente. Isso não é possível em Delphi, e pessoalmente, acho isso uma vantagem. A mistura do código com o layout deixa tudo bem mais complicado.

Neste ponto, sinta-se a vontade de colocar um Label e um Button, e escrever o clássico:

procedure TWebForm1.Button1_Click(sender: System.Object; e: System.EventArgs);
begin
  Label1.Text := 'Hello World';
end;

Daí é só rodar e ver funcionar.

Trabalhando no designer você vai perceber o Tag Editor logo abaixo dele, que mostra o html do ítem selecionado. Ele possui uma toolbar com duas setinhas, Zoom Out e Zoom In, que alteram a seleção um ítem para o que o contém, atualizando o designer o object inspector.

Outro demo bastante comum, mas simples de fazer para ganhar familiaridade é colocar um ListBox, um Button e um TextBox (também conhecido para nós como Edit), e escrever:

procedure TWebForm1.Button2_Click(sender: System.Object; e: System.EventArgs);
begin
  ListBox1.Items.Add(TextBox1.Text);
end;

Fazendo isso você deve ter percebido o comportamento padrão do designer ASP.Net: o “flow layout”: componentes ficam um em seguida do outro, como em um processador de texto. É tão parecido com um processador de texto, aliás, que você pode digitar no editor para criar o texto da página, enter cria parágrafos, e assim por diante. Dando Zoom Out até o objeto Document você vai encontrar uma propriedade PageLayout, que pode ser alterada para GridLayout permitindo assim a colocação de componentes com coordenadas X e Y na página. Não recomendo o uso de Grid Layout – é prático de montar mas o resultado depois não é bom e é difícil de se customizar.

A partir daí é fácil programar boa parte da lógica que você está acostumado até hoje, só que em uma aplicação ASP.Net. Mas nunca se esqueça, uma aplicação web não é a mesma coisa que uma aplicação desktop, e nem deveria ser. Vou falar mais disso (e mais sobre ASP.Net) em artigos futuros.