A3

CICLO DE VIDA DE UMA PGINA

A correcta concepo de pginas ASP.NET est directamente dependente da compreenso do seu ciclo de vida. Uma pgina ASPX percorre vrias etapas, desde a altura que instanciada at ser destruda. Algumas dessas etapas importantes so sinalizadas atravs de eventos; outras atravs de mtodos virtuais especiais que podem ser modificados nas classes derivadas. Algumas das fases ocorrem durante todos os tipos de pedidos; outras ocorrem apenas durante postbacks ou simplesmente no existem quando estamos numa situao de callback.

A3.1 TRAJECTO DE UM PEDIDO ASP.NET

Todos os pedidos efectuados sobre recursos controlados pelo ASP.NET passam, em primeiro lugar, pelo servidor IIS. Antes do lanamento do IIS 7, todos os recursos ASP.NET eram processados pela extenso aspnet_isapi.dll, cuja principal funo controlar o processo aspnet_wp.exe, que efectua o hosting do CLR de forma a tratar os pedidos efectuados. No interior deste processo, so criados vrios AppDomains tantos quantas as aplicaes ASP.NET existentes no servidor. A partir da altura em que o pedido redireccionado para um AppDomain, passa por vrios elementos at ser tratado pela classe obtida atravs do parsing da pgina. Estes elementos constituem o chamado PIPELINE ASP.NET. Com o lanamento do IIS 7, a integrao entre a plataforma ASP.NET e o servidor total e a pipeline ASP.NET passa a ser reutilizada pelo IIS. A classe ISAPIRuntime serve de ponto de entrada da pipeline. O primeiro objecto importante criado por esta classe um objecto do tipo HttpWorkerRequest (responsvel por manter dados associados ao pedido actual por exemplo: URL, headers HTTP enviados no pedido, etc.) que passado como argumento ao mtodo ProcessRequest da classe HttpRuntime. O objecto HttpRuntime comea por criar o contexto associado ao pedido actual com base nos dados recebidos. Este contexto, representado por uma instncia da classe HttpContext, um dos elementos mais importantes da pipeline e permite-nos
FCA Editora de Informtica

ASP.NET 4.0 CURSO COMPLETO

aceder a vrios objectos usados durante o tratamento de um pedido (por exemplo: HttpApplicationState, HttpResponse, etc.) ver figura A3.1.

FIGURA A3.1 Incio do tratamento de um pedido ASP.NET na pipeline

a classe HttpRuntime recorre ao factory HttpApplicationFactory para obter uma instncia do tipo HttpApplication (ou de um tipo derivado desta classe) adequada ao pedido actual. Refira-se que, na maior parte das vezes, esta instncia proveniente de uma pool de elementos desse tipo mantida pela plataforma. Esta instncia responsvel por carregar e inicializar todos os mdulos associados aplicao actual (isto , a classe inicializa todas as classes que implementam a interface IHttpModule e que esto registadas na seco <httpModules> do ficheiro de configurao) ver figura A3.2.

Em

seguida,

FIGURA A3.2 Criao de HttpApplication e carregamento de mdulos .

FCA Editora de Informtica

ANEXO 3 - CICLO DE VIDA DE UMA PGINA

Aps inicializar os mdulos, a classe HttpApplication instancia uma handler capaz de satisfazer o pedido actual (note-se que esta procura feita com base no tipo de recurso pedido que identificado atravs do URL). Todos os pedidos efectuados sobre um ficheiro ASPX so tratados pela classe PageHandlerFactory, sendo esta classe tambm um factory que se limita a instanciar a pgina adequada ao tratamento final do pedido. Por sua vez, a pgina implementa uma de duas interfaces, IHttpHandler ou IHttpAsyncHandler: a primeira, implica o tratamento do pedido de forma sncrona; a segunda, efectua esse tratamento de forma assncrona. Note-se que este elemento o responsvel por preencher o buffer que contm a resposta enviada para o lado cliente. Este envio dos dados sinaliza o fim do tratamento do pedido (figura A3.3).

FIGURA A3.3 Obteno

da handler responsvel pelo tratamento do pedido

Alguns dos elementos apresentados nos diagramas anteriores podem ser modificados de forma a suprimir algumas lacunas ou a expandir as capacidades da plataforma. As handlers e os mdulos so dois dos elementos mais usados para estender as funcionalidades disponibilizadas pela plataforma: uma handler responsvel por tratar um pedido, ou seja, uma handler ser sempre a destinatria final de um pedido, sendo a responsvel por gerar a resposta enviada ao cliente. Logo, todas as pginas ASPX no so mais do que handlers capazes de satisfazer um determinado pedido; por outro lado, um mdulo uma classe capaz de interceptar os pedidos efectuados para conseguir influenciar o pedido recebido ou a resposta enviada.

A3.2 CLASSE HTTPCONTEXT

A classe HttpContext est presente desde o incio at concluso do tratamento do pedido. Como vimos, o tratamento de cada pedido comea por
FCA Editora de Informtica

ASP.NET 4.0 CURSO COMPLETO

obter uma instncia vlida deste elemento que passado como parmetro a todos os intervenientes na pipeline. Para alm de encapsular dados provenientes do protocolo HTTP atravs de propriedades do tipo HttpResponse e HttpRequest, esta classe fornece ainda acesso aos dicionrios de sesso (propriedade Session, do tipo HttpSession) e de aplicao (propriedade Application, do tipo HttpApplicationState), representados por instncias do tipo HttpSessionUtility, Cache e HttpApplicationState. A propriedade Cache fornece-nos acesso a um objecto do tipo Cache que funciona como um dicionrio global capaz de manter valores ao longo dos pedidos efectuados. A cache apresenta um sistema de expirao responsvel por invalidar entradas quando determinadas condies (definidas pelo programador) so verificadas. A propriedade Current esttica e permite-nos obter uma referncia ao contexto actual, possuindo ainda outra propriedade muito interessante designada por Items. Esta propriedade fornece-nos um dicionrio capaz de manter os valores ao longo do tratamento de um pedido (algo que se torna atractivo para os mdulos existentes ao longo da pipeline este dicionrio pode ser utilizado para adicionar um valor no incio do pedido que ser recuperado numa fase mais adiantada desse pedido). Os dados que identificam o utilizador actual podem ser obtidos atravs das propriedades User e Profile. Finalmente, podemos influenciar alguns aspectos da aplicao atravs da propriedade ApplicationInstance, que retorna uma referncia a um objecto do tipo HttpApplication. importante no confundir a classe HttpApplication com a classe HttpApplicationState. Os elementos do tipo HttpApplication so utilizados para controlar a aplicao actual e so obtidos atravs do parsing do ficheiro global.asax (como veremos em seguida). A classe possui tambm alguns mtodos interessantes. Por exemplo, o mtodo RewritePath utilizado para atribuir um novo URL, fazendo com que o URL interno seja diferente do pedido efectuado pelo utilizador. Esta tcnica usada para permitir o mapeamento de URLs.

A3.3 CLASSE HTTPAPPLICATION

Aps inicializar o contexto, o objecto HttpRuntime cria um objecto do tipo HttpApplication. O tipo de classe associado a uma aplicao pode ser personalizado atravs da utilizao do ficheiro global.asax. Este ficheiro, que deve ser colocado na pasta de topo da aplicao, normalmente constitudo por
FCA Editora de Informtica

ANEXO 3 - CICLO DE VIDA DE UMA PGINA

mtodos definidos no interior de um bloco script servidor, cujo principal objectivo tratar um ou mais eventos gerados pela aplicao ou por um dos mdulos existentes na pipeline. A classe HttpApplication possui vrios eventos importantes que podem ser tratados atravs da adio de mtodos ao ficheiro global.asax (a sequncia de eventos encontra-se discriminada em http://msdn.microsoft.com/en-us/library/bb470252.aspx). O processamento destes eventos deve ser efectuado la AutoEventWireUp, ou seja, se, por exemplo, necessitarmos de processar o evento EndRequest, devemos utilizar cdigo semelhante ao seguinte:
void Application_EndRequest( object sender, EventArgs args ){
//...CDIGO ADEQUADO AO TRATAMENTO DO EVENTO}

O nome do mtodo encarregue de tratar um evento gerado por um mdulo segue os mesmos princpios apresentados no pargrafo anterior. A nica observao importante reside no facto de a primeira parte do nome utilizado no mtodo ser obtida a partir do registo do mdulo efectuado no ficheiro de configurao. Por exemplo, se observarmos o registo do mdulo FormsAuthentication, deparamo-nos com o seguinte:
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" />

Se estivermos interessados em processar os eventos gerados por este mdulo, ento, devemos construir os mtodos de acordo com a sintaxe FormsAuthentication_XXX (em que XXX representa o evento que desejamos tratar). Na maior parte das vezes, as funcionalidades implementadas atravs do ficheiro global.asax podem tambm ser implementadas atravs da construo de mdulos personalizados. Contudo, existem alguns eventos que apenas podem ser tratados por instncias da classe HttpApplication, como, por exemplo, os eventos de incio, de fim de sesso e de aplicao.

A3.4 CLASSE PAGEHANDLERFACTORY

Se o recurso pedido consistir numa pgina ASPX, a classe HttpApplication procede criao de um objecto do tipo System.Web.UI.PageHandlerFactory, sendo esta handler responsvel por instanciar a pgina adequada ao tratamento do pedido actual. Esta classe tambm responsvel por criar dinamicamente a assembly, atravs do parsing da pgina ASPX, e por carreg-la. A criao dinmica
FCA Editora de Informtica

ASP.NET 4.0 CURSO COMPLETO

da assembly efectuada quando no recorremos pr-compilao do site. Nestes casos, o primeiro pedido efectuado sobre uma pgina resulta no processo de compilao (normalmente efectuado em lote ou batch) que influencia negativamente o tempo de resposta desse primeiro pedido (refira-se que todos os outros pedidos subsequentes no necessitam de efectuar a compilao). A3.4.1 COMPILAO DINMICA DE PGINAS Todas as pginas ASPX so convertidas em classes definidas no interior de assemblies geradas dinamicamente e armazenadas numa subpasta (normalmente localizada em %windir%\Microsoft.Net\Framework\{verso}\ Temporary ASP.NET Files\Nome da aplicao). No interior desta pasta, possvel encontrarmos vrios directrios que contm os ficheiros utilizados durante a compilao e as dlls da resultantes. A propriedade CodegenDir exposta pela classe HttpRuntime indica a localizao correcta das pastas que contm as dlls que esto a ser utilizadas pela aplicao (figura A3.4).

FIGURA A3.4 Pasta temporria usada para compilar pginas e construir dls

FCA Editora de Informtica

ANEXO 3 - CICLO DE VIDA DE UMA PGINA

A transformao de uma pgina ASPX numa assembly um processo complexo constitudo por vrios passos (recorde-se que o anexo A1 apresentou as principais diferenas entre o tipo de compilao aplicado quando utilizamos projectos do tipo Web Site e Web Application). O primeiro passo consiste em efectuar o parsing s pginas ASPX. Durante este passo, todas as tags servidor (isto , com o atributo runat=server) definidas numa pgina so transformadas em campos internos das classes. O processo de parsing adiciona tambm os mtodos definidos no interior das tags de <script> classe final. Note-se que esta classe ainda influenciada pelos vrios atributos definidos nas directivas aplicadas a uma pgina. Para ilustrar este processo, vamos analisar o que acontece pgina ex1.aspx (apresentada no captulo 1 do livro) quando efectuado um pedido sobre esse recurso. O cdigo desta pgina o seguinte:
<%@ Page Language="C#" %> <script runat="server"> private void ProcessClick( object sender, EventArgs args ) { info.Text = "Ol, " + name.Text; } </script> <html> <head runat="server"> <title>Untitled Page</title> </head> <body> <form id="form1" runat="server"> <h3>Ol mundo!</h3> Introduza o seu nome na caixa: <asp:TextBox runat="server" ID="name" /> <asp:Button ID="bt" runat="server" Text="Saudao" OnClick="ProcessClick"/> <br /> <asp:Label ID="info" runat="server" /> </form> </body>
FCA Editora de Informtica

ASP.NET 4.0 CURSO COMPLETO

</html>

Aps efectuado o parsing da pgina, obtemos a seguinte classe (editada devido ao espao disponvel):
namespace ASP { //importacao de namespace removidas [CompilerGlobalScopeAttribute()] public class OlaMundo_aspx : global::System.Web.UI.Page, System.Web.SessionState.IRequiresSessionState { protected global::System.Web.UI.WebControls.TextBox name; protected global::System.Web.UI.WebControls.Button bt; protected global::System.Web.UI.WebControls.Label info; protected global::System.Web.UI.HtmlControls.HtmlForm form1; private static bool @__initialized; private static object @__fileDependencies; private void ProcessClick( object sender, EventArgs args ) { info.Text = "Ol, " + name.Text; } public OlaMundo_aspx() { string[] dependencies; AppRelativeVirtualPath = "~/Cap01/OlaMundo.aspx"; if ((global::ASP.OlaMundo_aspx.@__initialized == false)) { dependencies = new string[1]; dependencies[0] = "~/Cap01/OlaMundo.aspx"; global::ASP.OlaMundo_aspx.@__fileDependencies = this.GetWrappedFileDependencies(dependencies); global::ASP.OlaMundo_aspx.@__initialized = true; } this.Server.ScriptTimeout = 30000000; } //MTODOS/PROPRIEDADES NO INTERESSANTES REMOVIDOS //MTODO RESPONSVEL PELA CONSTRUO DA TEXTBOX NAME
FCA Editora de Informtica

ANEXO 3 - CICLO DE VIDA DE UMA PGINA private global::System.Web.UI.WebControls.TextBox @__BuildControlname() { global::System.Web.UI.WebControls.TextBox @__ctrl; @__ctrl = new global::System.Web.UI.WebControls.TextBox(); this.name = @__ctrl; @__ctrl.ApplyStyleSheetSkin(this); @__ctrl.ID = "name"; return @__ctrl; } //MTODO RESPONSVEL PELA CONSTRUO DO BOTO SAUDAO private global::System.Web.UI.WebControls.Button @__BuildControlbt() { global::System.Web.UI.WebControls.Button @__ctrl; @__ctrl = new global::System.Web.UI.WebControls.Button(); this.bt = @__ctrl; @__ctrl.ApplyStyleSheetSkin(this); @__ctrl.ID = "bt"; @__ctrl.Text = "Saudao"; @__ctrl.Click += new System.EventHandler(this.ProcessClick); return @__ctrl; } //MTODO RESPONSVEL PELA CONSTRUO DO FORMULRIO private global::System.Web.UI.HtmlControls.HtmlForm @__BuildControlform1() {

global::System.Web.UI.HtmlControls.HtmlForm @__ctrl; @__ctrl = new global::System.Web.UI.HtmlControls.HtmlForm(); this.form1 = @__ctrl; @__ctrl.ID = "form1"; System.Web.UI.IParserAccessor @__parser = ((System.Web.UI.IParserAccessor)(@__ctrl)); @__parser.AddParsedSubObject(new System.Web.UI.LiteralControl
FCA Editora de Informtica

10

ASP.NET 4.0 CURSO COMPLETO (" \r\n <h3>Ol mundo!</h3> \r\n Introduza o seu nome na caixa: ")); global::System.Web.UI.WebControls.TextBox @__ctrl1; @__ctrl1 = this.@__BuildControlname(); @__parser.AddParsedSubObject(@__ctrl1); @__parser.AddParsedSubObject(new System.Web.UI.LiteralControl("\r\n "));

global::System.Web.UI.WebControls.Button @__ctrl2; @__ctrl2 = this.@__BuildControlbt(); @__parser.AddParsedSubObject(@__ctrl2); @__parser.AddParsedSubObject(new System.Web.UI.LiteralControl("\r\n ")); <br />\r\n

global::System.Web.UI.WebControls.Label @__ctrl3; @__ctrl3 = this.@__BuildControlinfo(); @__parser.AddParsedSubObject(@__ctrl3); @__parser.AddParsedSubObject(new System.Web.UI.LiteralControl("\r\n ")); return @__ctrl; } //MTODO RESPONSVEL PELA CONSTRUO DA RVORE DE CONTROLOS private void @__BuildControlTree(OlaMundo_aspx @__ctrl) { System.Web.UI.IParserAccessor @__parser = ((System.Web.UI.IParserAccessor)(@__ctrl)); @__parser.AddParsedSubObject(new System.Web.UI.LiteralControl("\r\n<html>\r\n")); global::System.Web.UI.HtmlControls.HtmlHead @__ctrl1; @__ctrl1 = this.@__BuildControl__control2(); @__parser.AddParsedSubObject(@__ctrl1); @__parser.AddParsedSubObject(new System.Web.UI.LiteralControl("\r\n<body>\r\n <form></form>\r\n ")); global::System.Web.UI.HtmlControls.HtmlForm @__ctrl2; @__ctrl2 = this.@__BuildControlform1(); @__parser.AddParsedSubObject(@__ctrl2);

FCA Editora de Informtica

ANEXO 3 - CICLO DE VIDA DE UMA PGINA

11

@__parser.AddParsedSubObject(new System.Web.UI.LiteralControl("\r\n</body>\r\n</html>\r\n")); } //RESPONSVEL PELO INCIO DA CONSTRUO DA RVORE DE CONTROLOS DA PGINA protected override void FrameworkInitialize() { base.FrameworkInitialize(); this.@__BuildControlTree(this); this.AddWrappedFileDependencies(global::ASP.OlaMundo_aspx.@__ fileDependencies); this.Request.ValidateInput(); } public override int GetTypeHashCode() { return -160167019; } } }

Todos os controlos anotados com o atributo runat=server so transformados em campos protegidos da classe final; para alm disso, cada um dos controlos construdo atravs de um mtodo __BuildControlXXX responsvel por inicializar as propriedades de cada controlo a partir dos valores declarados nos atributos definidos na tag, na pgina ASPX. Esses mtodos so invocados a partir do mtodo @__BuildControlform1, fazendo com que todos os controlos definidos no interior do formulrio sejam adicionados sua coleco de controlos. Todo o processo de construo da rvore de controlos gerido pelo mtodo @__BuildControlTree. Convm ainda notar que o mtodo transforma todas as tags que no tm o atributo runat=server em controlos do tipo Literal de forma a poderem ser adicionados correctamente rvore de controlos da pgina.

A3.5 CICLO DE VIDA DA PGINA: MTODO PROCESSREQUEST

Aps encontrar a classe capaz de satisfazer o pedido actual, o objecto do tipo PageHandlerFactory instancia-a atravs do mtodo GetHandler. Como vimos, todas as pginas herdam directa ou indirectamente da classe Page que, por sua vez, implementa a interface IHttpHandler que possui apenas um
FCA Editora de Informtica

12

ASP.NET 4.0 CURSO COMPLETO

mtodo: ProcessRequest. A classe Page implementa este mtodo de forma a gerar todas as fases que constituem o ciclo de vida da pgina. Note-se que a invocao deste mtodo ser efectuada atravs da instncia do tipo HttpRuntime que iniciou o tratamento do pedido (portanto, a instncia da pgina criada pelo objecto PageHandlerFactory passada ao objecto HttpApplication que, por sua vez, devolve esse elemento instncia HttpRuntime que iniciou todo o processo na pipeline). O mtodo ProcessRequest comea por invocar o mtodo virtual FrameworkInitialize, cuja principal funo construir a rvore de controlos da pgina. Este mtodo sempre implementado pela classe final obtida a partir do parsing da pgina ASPX (figura A3.5). Antes de entrarmos na etapa de inicializao o mtodo ProcessRequest efectua algumas operaes auxiliares: primeiro, recorre ao mtodo DeterminePostbackMode, de forma a determinar se estamos ou no em modo de postback; segundo, determina se ou no necessrio exportar uma Web Part (invocao do mtodo DetermineIsExportingWebPart) e, terceiro, tenta verificar se o pedido actual um callback (figura A3.6). O evento PreInit marca o incio da etapa de inicializao da pgina e fornece-nos a ltima oportunidade de definio dinmica da master page e do theme aplicado pgina. Tal deve-se ao facto de a pgina proceder aplicao da master e do theme indicados atravs da execuo dos mtodos ApplyMasterPager e InitializeThemes, imediatamente aps a gerao deste evento. Aps proceder aplicao de uma (possvel) master page e de um (eventual) theme, segue-se o evento Init (propagado por todos os controlos existentes na pgina). Durante esta fase, um programador pode utilizar os controlos definidos na pgina ASPX, mas convm notar que o ViewState associado a cada controlo ainda no foi carregado. Em seguida, a monitorizao do ViewState activada atravs da execuo do mtodo TrackViewState. A etapa de inicializao termina oficialmente com a gerao do evento InitComplete.

FCA Editora de Informtica

ANEXO 3 - CICLO DE VIDA DE UMA PGINA

13

FIGURA A3.5 Fases internas associadas ao ciclo de vida da pgina

FCA Editora de Informtica

14

ASP.NET 4.0 CURSO COMPLETO

FIGURA A3.6 Operaes auxiliares efectuadas antes da etapa de inicializao

A etapa seguinte (que ocorre apenas durante postbacks) consiste na reconstituio do estado interno da pgina e dos controlos, atravs da recuperao dos dados mantidos no View State e no Control State. O carregamento de estado de um controlo engloba a execuo sequencial de vrios mtodos: o primeiro, designado por LoadPageStateFromPersistenceMedium, recupera os dados internos da pgina (e dos controlos nela definidos) a partir do meio onde estes foram armazenados no final do pedido anterior. Por predefinio, esses dados so guardados num controlo HTML INPUT enviado para o browser com o ID de __VIEWSTATE. Em seguida, a pgina percorre todos os controlos existentes na sua rvore de controlos, de forma a que cada controlo possa recuperar os seus dados mantidos no ViewState e no Control State. Durante essa operao, a pgina invoca os mtodos virtuais LoadControlState e LoadViewState (definidos pela classe Control) sobre cada um desses controlos. O primeiro mtodo permite a recuperao do chamado estado interno de um controlo; por sua vez, o mtodo LoadViewState permite recuperar os dados mantidos no View State. A fase de recuperao e actualizao de dados termina com o mtodo ProcessPostData. Este mtodo encontra todos os controlos que implementam a interface IPostBackDataHandler, de forma a possibilitar a actualizao do estado interno desses controlos com os dados provenientes do formulrio submetido (esta actualizao feita atravs da execuo do mtodo LoadPostData sobre todos os controlos que implementam essa interface). O evento PreLoad sinaliza a altura em que os controlos definidos de forma declarativa na pgina j foram devidamente actualizados. Segue-se o evento Load, propagado por todos os controlos inicializados e adicionados rvore de controlos da pgina. Durante esta fase, e apenas quando estamos em
FCA Editora de Informtica

ANEXO 3 - CICLO DE VIDA DE UMA PGINA

15

modo de postback, o mtodo ProcessPostData volta a ser executado, dando assim uma segunda hiptese aos controlos adicionados dinamicamente pgina (durante o evento Load) que implementam a interface IPostBackDataHandler para recuperarem os dados provenientes do cliente, de modo a actualizarem o seu estado interno. Em seguida, chegada a altura de gerar os eventos servidor dos controlos. A pgina comea por invocar o mtodo RaisePostBackDataChangedEvent de todos os controlos que implementam a interface IPostBackDataHandler, dando-lhes assim a oportunidade de gerarem eventos associados modificao dos dados relativos ao seu estado interno (por exemplo: evento TextChanged gerado pelo controlo TextBox). O controlo responsvel pelo postback identificado e, caso esse controlo implemente a interface IPostBackEventHandler, a pgina procede invocao do mtodo RaisePostBackEvent desse controlo (figura A3.7). Normalmente, os controlos implementam este mtodo de forma a gerarem um determinado evento personalizado exposto pelo controlo (por exemplo: evento Click de um boto). A fase relativa ao carregamento de dados termina oficialmente com o evento OnLoadComplete.

RaiseChangedEvents

RaisePostbackEvent

FIGURA A3.7 Mtodos usados para gerar eventos servidor durante postback

Concludas as operaes de carregamento de dados e a respectiva gerao de eventos associados a essas alteraes, chegada a altura de gerar o HTML da pgina. Esta etapa inicia-se com o evento PreRender o tratamento deste evento fornece-nos uma das ltimas hipteses de influenciar o aspecto final (leia-se HTML) de cada um dos controlos que constituem a pgina. O evento PreRenderComplete sinaliza o trmino da fase relativa pr-gerao da pgina.
FCA Editora de Informtica

16

ASP.NET 4.0 CURSO COMPLETO

Em seguida, a pgina inicia o armazenamento dos dados internos mantidos por todos os controlos (que englobam os dados mantidos no view state e no Control State). Isto implica a execuo recursiva do mtodo SaveViewState e SaveControlState sobre todos os elementos existentes na rvore de controlos da pgina. O processo culmina com a execuo do mtodo SavePageToPersistenceMedium, que efectua a operao inversa do mtodo LoadPageStateFromPersistenceMedium (este mtodo limita-se a guardar todos os dados num controlo HTML INPUT escondido que enviado para o lado cliente figura A3.8). A concluso destas operaes ser sinalizada atravs do evento SaveStateComplete.
SaveAllState

SaveViewState

SaveControlState

SavePageStateToPersistenceMedium

FIGURA A3.8 Armazenamento de dados no final do pedido

, ento, chegada a altura de gerar o HTML que ser enviado para o cliente atravs da execuo do mtodo RenderControl. Este processo recursivo obriga a que todos os controlos participem, para que o HTML final seja constitudo pelo somatrio do HTML gerado por todos os controlos existentes na rvore de controlos da pgina. Resta apenas efectuar a limpeza de eventuais recursos utilizados durante o processamento. O evento a ter em ateno o evento Unload. A3.5.1 PGINAS ASSNCRONAS A utilizao de pginas assncronas modifica ligeiramente o ciclo apresentado na seco anterior. Nestas situaes, a pgina processada normalmente at ao evento LoadComplete. Neste instante, todas as tarefas assncronas so iniciadas atravs da execuo do mtodo ExecuteRegisteredAsyncTasks e a thread usada para satisfazer o pedido retorna pool de threads associada aplicao. Aps a concluso de todas as tarefas
FCA Editora de Informtica

ANEXO 3 - CICLO DE VIDA DE UMA PGINA

17

assncronas (ou aps ter sido obtido um timeout), o processamento da pgina ser retomado com o evento PreRender. A partir desta altura, todas as fases apresentadas anteriormente so executadas sequencialmente. A3.5.2 CALLBACKS O ciclo apresentado ligeiramente diferente quando estamos em modo de callback. Nestas situaes, o ciclo de vida segue todos os passos apresentados at ao evento LoadComplete. Aps este evento, a pgina invoca o mtodo RaiseCallbackEvent sobre o controlo responsvel pelo callback e prossegue com o ciclo de vida da pgina. O processamento da pgina termina antes do evento PreRender com a invocao do mtodo GetCallbackResult sobre o controlo que iniciou o pedido. Note-se que a utilizao de callbacks suporta a execuo de tarefas assncronas. A3.5.3 ADAPTADORES A descrio associada ao ciclo de vida de uma pgina no ficaria completa sem apresentarmos os adaptadores. A principal funo destes componentes permitir a abstraco do dispositivo para o qual um controlo gera HTML. Na verso 1.X da plataforma, os programadores de controlos Web eram obrigados a verificar as capacidades do browser antes de gerarem o HTML que representava o estado do controlo. Este tipo de verificaes pode ser completamente eliminado com a utilizao deste tipo de componentes. A ideia simples: sempre que for necessrio personalizar o comportamento de um determinado controlo para um determinado browser, ento, o programador dever construir um novo adaptador que ser responsvel por gerar o contedo adequado a esse browser. Na prtica, os adaptadores so classes derivadas (directa ou indirectamente) da classe ControlAdapter. Todos os controlos possuem uma propriedade (protegida) designada por Adapter. O primeiro acesso a esta propriedade responsvel por inicializar o adaptador (normalmente a classe Control limita-se a obter o adaptador a partir do mtodo GetAdapter existente na classe HttpBrowserCapabilities). Se o mtodo retornar um adaptador vlido, ento, este elemento poder influenciar o comportamento do controlo.

FCA Editora de Informtica

18

ASP.NET 4.0 CURSO COMPLETO

A informao especfica de cada browser guardada num ficheiro de XML de extenso .browser. A diviso em ficheiros externos teve por objectivo remover toda essa informao do ficheiro machine.config, de forma a facilitar a manuteno dos ficheiros. Cada ficheiro contm vrias entradas que permitem definir as caractersticas especficas de cada browser (por exemplo, se suporta ou no JavaScript). Para alm disso, conseguem tambm definir a relao entre um controlo e um determinado adaptador. Essa relao descrita no interior da seco <controlAdapters>. A verso 4.0 introduziu ainda o conceito de provider para a definio das caractersticas de um browser. Um provider deste tipo tem apenas de utilizar a classe HttpCapabilitiesProvider com base e efectuar o override do mtodo GetBrowserCapabilities de forma a devolver um objecto do tipo HttpBrowserCapabilities devidamente preenchido.

Onlnit

Onlnit

Carregar estado do controlo (Control state e viewstate)

Carregar estado do adaptador (Control state e viewstate)

OnLoad

OnLoad

O Controlo permite ao adaptador manter/recuperar o seu estado interno

OnPreRender

OnPreRender

Guardar estado controlo (Control state e viewstate)

Guardar estado adaptador (Control state e viewstate)

Render

Render

FIGURA A3.9 Interaco entre controlo e adaptador

FCA Editora de Informtica

ANEXO 3 - CICLO DE VIDA DE UMA PGINA

19

A utilizao deste tipo de elementos implica uma ligeira modificao no ciclo apresentado anteriormente. Isto deve-se ao facto de o adaptador participar activamente no ciclo de vida do controlo associado. importante percebermos que esta deciso tomada pelo adaptador: caso no deseje participar activamente num evento, ento, limita-se simplesmente a nada fazer e a responsabilidade do processamento fica a cargo do controlo. Para alm de permitir a interaco entre o controlo e o adaptador ao longo dos principais eventos de um controlo, a classe Control permite ainda aos adaptadores manterem o seu prprio estado interno (atravs de View State ou de Control State ver figura A3.9).
CONCLUSO O tratamento de um pedido sobre um recurso ASP.NET um processo complexo que passa por vrias etapas, desde a altura em que a plataforma recebe o pedido at altura em que a resposta devolvida ao cliente. Ao longo deste captulo, analismos de forma detalhada todas as etapas associadas a um pedido efectuado sobre uma pgina ASP.NET. Como vimos, todos os pedidos atravessam uma pipeline constituda por vrios elementos at chegarem handler responsvel por efectuar o tratamento desses elementos. Ao longo do captulo, foi possvel verificar que existem alguns elementos que podem ser personalizados de forma a modificar o comportamento predefinido.

FCA Editora de Informtica