Sabemos que uma página ASP NET não sai de um arquivo em disco pronta para ser exibida. Normalmente o conteúdo da página é combinado com outros processos que, por exemplo, podem carregar dados de um banco de dados ou até acessar componentes externos do servidor ASP NET como no uso do SMTP do sistema operacional ( envio de e-mails).
Depois da página 'montada' no servidor ( renderizada ) ela é enviada em puro Html, css e JavaScript para o cliente.
Abaixo estão os principais eventos que ocorrem desde a solicitação da página até a entrega ao cliente.
Note que objetos como a Session e Cookies podem sobreviver mesmo depois da morte da página. Depois de alguns minutos ( no ASP NET o default é 20 minutos ) um processo corre no servidor e mata tudo que está há mais de 20 minutos sem uso no servidor. Os cookies ficam armazenados no disco do cliente e é um processo condenável de jogar lixo em máquinas dos outros sem pagar nada por isso.
PreInit : Neste evento são definidos dinamicamente (a partir do código) os valores como página mestra ou tema. Este evento também é utilizado quando dinamicamente adicionamos em uma página.
Init : Este evento é disparado após uma inicialização de cada controle como uma espécie de 'construtor' do elemento. Este evento é o ponto ideal para alterar os valores de inicialização dos controles.
InitComplete : Este evento é disparado quando todas as inicializações da página e seus controles forem concluídos.
PreLoad : Este evento é disparado antes da exibição e antes do processamento PostBack. Este evento é útil quando precisamos escrever um código após a página ter sido inicializada, mas antes que o estado de visualização.
Load ( Carregar ) : Este evento você conhece bem, se você tem um combobox que precisa ser carregado com valores 'default', se você precisa carregar um gridview com dados assim que a página ficar pronta é aqui que você faz isso. Cada controle da página é carregado com informações neste evento.
Eventos do controle (Control event(s) PostBack) : Um controle do lado do servidor executa um postback para exigir um processamento do servidor como, por exemplo, o clique de botão. Lembre-se que na primeira linha da página web asp net podemos definir 'AutoPostBack=True' e assim todos os controles do form terão seu postback ou podemos definir o 'AutoPostBack' num controle específico.
LoadComplete : Neste ponto todos controles estão prontos e carregados com dados. Este é o ponto ideal para rotinas de alteram a apresentação da informação como colocar o fundo da linha do dado em vermelho se uma dada coluna da linha for negativo.
PreRender : Este evento ocorre antes da página começar a ser renderizada e antes de salvar ViewState, portanto, quaisquer alterações feitas aqui serão salvas pelo ViewState.
SaveStateComplete : A partir deste ponto quaisquer alterações nos controles da página neste ponto ou além são ignoradas.
Render : Na realidade render é um método do objeto da página e não um evento. Neste ponto, o ASP.NET chama esse método em cada um dos controles da página para obter sua saída. O método render gera o HTML do lado do cliente, Hipertexto Dinâmico Linguagem de marcação (DHTML) e script que são necessários para exibir adequadamente um controle no navegador . No final deste método a página HTML com todo seu conteúdo é enviada ao browser do usuário.
UnLoad : Este evento é usado para realizar a limpeza das informações criadas pelo código da página. Você pode usar este evento para liberar qualquer recurso nesta fase.
Note que o ASP NET gerencia automaticamente os recursos que são alocados quando necessários e liberados quando não são especialmente no tempo de execução, como instâncias de classes criadas pelo tempo de execução de linguagem comum do .NET. Você na aplicação aponta para os recursos...a carga e o descarte deles fica a cargo do ASP NET.
Note que o elemento é liberado ( objeto = Nothing), mas, por exemplo, a memória ocupada por ele não é liberada até que a aplicação web se encerre e o 'limpador de lixo' (garbage collector) rode e libere os recursos, como é feito no Java. Note que este processo de limpeza é pesado e não é possível rodar ele em um ambiente em produção sem causar impactos significativos em sua performance. Mais uma prova que o ASP NET é plágio do Java.
O ASP NET já tem um mecanismo de atualização próprio da linguagem mas muitas pessoas acham 'deselegante' fazer uma requisição ao servidor ASP NET quer 'recarregaria' toda a página novamente.
Com o AJAX podemos 'atualizar' o conteúdo corrente da página, de uma parte dela, sem recarregar a página toda. Fica muito mais 'bonito', 'elegante' mas como dizemos, não tem nada grátis em TI.
Como no AJAX tudo é feito em JavaScript a atualização do conteúdo da página é feita via HTTP request do HTML.
Contudo ao enviar a página ao servidor ( via 'postback' ou 'submit' do ASP NET ) os elementos enviados pelo AJAX não
são reconhecidos pelo servidor e serão descartados pois o ASP NET não reconhece esses elementos porque não foi
ele quem enviou.
Outro problema é a segurança dos processos do AJAX...não podemos deixar processos 'não identificados' gerar requisições em nossos servidores. Mesmo com processos autenticados é fácil burlar a segurança e gerar um ataque tipo 'DDOS', ou seja, criar uma sobrecarga nos serviços do servidor que acaba derrubando o serviço.
É bom relembrar o processo do AJAX porque em ASP NET ele é uma alternativa não o foco da ferramenta. Eu não recomendo o uso do AJAX muito menos em processos JavaScript fazendo requisições ao servidor ASP NET a não ser que o componente que esteja fazendo a requisição do serviço seja feito pelo próprio ASP NET que assegura a autenticação da requisição pelo ScriptManager e ViewState.
AJAX significa JavaScript Assíncrono em Inglês. Assíncrono significa que ele dispara um processo ( via HTTP Request), mas não espera seu 'retorno'. Um outro evento é disparado quando a informação chegar ( HTTP Response). Isto significa que o AJAX não 'segura' a página, ou seja, impede que ela seja carregada até o fim enquanto aguarda um retorno.
Isso é bom por um lado e ruim por outro. É bom que ele não aguarde porque a página é carregada sem demora. Contudo se o retorno da informação demorar ou mesmo não chegar pode ser que a página fique sem sentido algum, o essencial ficou faltando.
Dentro do próprio AJAX podemos interceptar os eventos que são disparados quando o processo chega a uma determinada etapa. Isso é fundamental para o tratamento de processos assíncronos já que ao fazer uma requisição o AJAX não espera o retorno da informação, ele simplesmente encerra o processo. Quando a informação retorna um evento é disparado no AJAX para continuar o processo.
Os eventos que podem ser gerados pelos controles Ajax são gerenciados pelo código dentro da página que chamam as definições deles feitas dentro da namespace Sys.WebForms.
Note que o AJAX é basicamente um JavaScript assíncrono em relação a página e o cadenciamento dos eventos do seu ciclo de vida são regidos por 2 componentes distintos :
• 1 - O primeiro é na própria página ASP NET que dispara o evento AJAX via HtmlHTTPRequest.
• 2 - O segundo elemento envolvido é o servidor que processa a requisição AJAX e retorna com o erro ou com os
dados.
Retornando os dados eles serão carregados na página ASP NET pelo componente que gerou a
solicitação AJAX.
Os eventos num processo Ajax dentro de uma página ASP NET são :
initializeRequest : Gerado antes do início do PostBack assíncrono.
beginRequest : Gerado quando o PostBack assíncrono é enviado ao servidor.
pageLoading : Gerado quando a resposta assíncrona PostBack retorna do servidor.
pageLoaded : Gerado depois que o conteúdo foi carregado a partir dos resultados do assíncrono PostBack.
endRequest : Gerado quando o PostBack assíncrono foi concluído.
Como disse acima jamais use o AJAX para iniciar processos que possam 'carregar' significativamente o servidor e que tragam muita informação.