Capítulo 3: Handling Events and Managing State Lição 3: Using Server-Side State Management

Do contrário da lição 2, a lição 3 mostra as técnicas de gerenciamento de sessão no servidor. Você deve gerenciar os estados no servidor quando existe uma quantidade grande de dados e se torna oneroso a ida e vinda desses dados entre o cliente e o servidor. Outro grande motivo é a segurança, podemos trabalhar com dados sigilosos que não podem correr o risco de ficar disponível na máquina do cliente.

O asp.net disponibiliza duas formas de gerenciar pelo servidor, essas formas já foram citadas em lições anteriores. Os métodos são Application State e Session State.

O primeiro é global, ou seja, os dados são acessados por todos os usuário em qualquer página. Os dados armazenados no Application State são os mesmos para todos os usuários. Já o segundo método Session State é único por cada usuário, cada usuário tem a sua sessão, da mesma forma que o Application State os dados armazenados em Session State são acessados em qualquer página.

Application State

Os dados armazenados no Application State são globais e podem ser acessados em qualquer requisição de qualquer página. A classe HttpApplicationState é um dicionário de chave e valor e pode ser acessado pelo nome do chave. Os dados armazenados no Application State não são permanentes, no momento em que a aplicação é reiniciada, por exemplo quando o IIS ou o servidor é iniciado os dados armazenados neste sessão são perdidos.

Session State

 Os dados armazenados com Session State também podem ser acessados de qualquer página, a grande diferença é que é único por usuário (browser). Por padrão esses dados são armazenados na memória do servidor, mas é possível  é configurar para utilizar cookies, em State Serve ou em um banco de dados.


De forma similar ao Application State, o Session State é um dicionário de chave e valor, como demonstra o código:


// Caso a sessão não exista
if (Session["lastVisit"] != null)
{
    Label1.Text = ((DateTime)Session["lastVisit"]).ToString();
}
else
{
    Label1.Text = "Session does not have last visit information.";
}
// Definindo um valor para a sessão
Session["lastVisit"] = DateTime.Now;

Caso queira desabilitar o uso de sessões pode fazer no web.config:
<configuration>
<system.web>
<sessionState mode="off"/>
</system.web>
</configuration>

Ou  definir na diretiva da página no caso de desabilitar em páginas especificas, utilizando a propriedade EnableSessionState:
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs"
Inherits="_Default" EnableSessionState = "False"%>

É possível configurar a forma com que irá utilizar sua sessão:

• InProc: é o modo padrão. É o que oferece melhor desempenho em relação as outras opções. No entanto ele fica limitado em cenários de balanceamento de carga entre servidores. Pois não terá como garantir que um usuário comece e termine seu processo no mesmo servidor.
• StateServer: Nesta configuração os dados armazenados na sessão não são perdidos quando a aplicação é reiniciada, e neste cenário é possível fazer o compartilhamento entre servidores. O StateServer é um serviço do asp.net que esta em qualquer máquina que possua o FrameWork instalado. Este serviço não é configurado para iniciar automaticamente e sim manualmente, por isso deve ser feito essa mudança para que inicie automaticamente caso deseja usar.
• SQLServer: Tem os mesmos benefícios do StateServer, armazena os dados quando a aplicação é iniciada e  pode ser utilizado em vários servidores. Em hardware idêntico o StateServer supera o SQLServer, porém o SQLServer oferece integridade dos dados mais robustos e capacidade de relatórios.
• Custom: Permite que você especifique uma sessão personalizada, necessitando do código para implementar seu armazenamento personalizado.
• Off: Desativa as Sessões, deve utilizar esta opção caso queira desabilitar sessões.

Assim se encerra o capítulo III.

Abraços...

Capítulo 3: Handling Events and Managing State Lição 2: Using Client-Side State Management

Esta lição mostra as principais maneiras de gerenciamento de estado do lado do cliente, desta forma economizando recursos do servidor.

As principais técnicas são:

• View state: O asp.net utiliza para controlar os valores dos controles entre as requisições da página.
• Control state: É possível persistir informações específicas do controle sem utilizar a View State, é muito utilizado em casos de controles personalizados.
• Hidden fields: Como a View State este campo fica no html mas não é renderizado para o usuário
• Cookies: Um cookie fica armazenado no navegador do usuário, para cada requisição que é enviada para o servidor o valor do cookie é enviado também, é a maneira mais recomendada quando é necessário acessar este valor em diferentes páginas do mesmo domínio.
• Query strings: É um valor informado pela url da página, fica visível ao usuário na barra de endereço do browser.

Antes de explicar sobre cada uma dessas formas de persistir os dados do lado do cliente, a lição explica vantagens e desvantagens de persistir os dados do lado do servidor e do lado do cliente.

Persistindo os dados no cliente, as vantagens são:

• Melhor Escalabilidade: Caso utiliza-se do lado do servidor, a cada acesso de um cliente/usuário aumenta o uso de memória do servidor. Jogando esta carga para o cliente para um irá absorver o seu acesso e irá ter um grande consumo de recurso do servidor.
• Suporte por Múltiplos Servidores: Caso você necessite de uma grande arquitetura de servidores, obter as informações do cliente que estão no browser será possível por qualquer servidor sem fazer um balanceamento de carga inteligente. Ou seja caso o usuário mude de servidor no meio de uma sessão, basta o servidor acessar os dados que estão no browser.

Vantagens de persistir os dados no servidor:

• Melhor Segurança: A menos que você assine digitalmente as informações que estão no cliente, qualquer um pode alterar os dados armazenados. Ou seja nunca armazene no cliente dados confidenciais como senhas e níveis de acesso.
• Redução de Banda: Os dados estando no servidor não é necessário o envio e recebimento dessas informações, os dados estando no cliente a cada requisição os dados são enviados ao servidor, utilizando banda do cliente e do seu servidor. O conselho é armazenar pequenas informações no cliente.

Qual usar? Agora é você que decide com bases nessas informações. Se você tiver uma aplicação com poucos usuário e informações sigilosas utiliza recursos do servidor. Se quer ganhar performance em sua aplicação utilize as duas formas, sabendo quando usar uma ou outra.

View State

View State é um mecanismo do asp.net para armazenar dados de um usuário entre as requisições da mesma página. A view state não é armazenada no servidor, fica no código html da página, ela armazena estados de exibição dos controles que são acessados entre cada requisição, não consumindo assim recursos do servidor.

Caso não desabilite a View State é padrão de todas as páginas. Um exemplo, quando faz uma consulta o servidor retorna os dados e o formulário é preenchido, quando o usuário alterar algum campo e clicar no botão gravar por exemplo, caso haja um erro no envio desses dados ao servidor, as informações já digitadas não será perdidas, pois os valores armazenados na View State permaneceram.

A View State é armazenada da seguinte forma no código html:
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE"
value="/wEPDwULLTEzNjkxMzkwNjRkZAVvqsMGC6PVDmbCxBlPkLVKNahk" />

Caso o valor seja muito grande a View State é quebrada em 2 ou quantas for necessária para armazenar  o valor. Repare que o valor é um hash e é compactado para oferecer maior segurança e maior performance que um campo hidden comum.

Como a View State ficar no código html, o usuário consegue modificar estes valores, porém o asp.net possui um código de autenticação que consegue validar se a View State foi alterada ou não.

Caso queira maior segurança para sua aplicação é possível criptografar suas View State através de uma configuração do Web.config:

<configuration>
<system.web>
<pages viewStateEncryptionMode="Always"/>
</system.web>
</configuration>

Só que desta forma irá perder um pouco de performance pois toda vez terá que ser feito a criptografia e a descriptografia. Uma alternativa seria criptografar somente as View State que forem realmente necessárias, colocando a diretiva diretamente na página:

<%@ Page Language="C#" AutoEventWireup="true" ViewStateEncryptionMode="Always"%>

Como disse por padrão a View State esta habilitada em todas as páginas e para todos os controles. Devido ao trafego de envio e recebimento de informações da View State você pode optar por desabilita-la.

Caso a página seja acessada por usuário de conexões lentas e sejam páginas com um grande número de controles, a lição especifica mais de 10 controles, vale a pena pensar na hipóteses de desabilita-la. Você deve controlar os dados que são armazenados na View State, para controlar a nível de página utilize as propriedades Page.EnableViewState e Page.ViewStateMode, para controles utilize Control.EnableViewState e Control.ViewStateMode.

A propriedades ViewStateMode é nova no FrameWork 4 e só terá efeito caso a propriedades EnableViewState esteja como true. Por padrão a ViewStateMode da Página tem o valor de Enabled e a propriedades ViewStateMode dos controles herdam o valor atribuido a propriedade da página.


Caso você defina o EnableViewState como falso a View State estara desabilitada independentemente do valor atribuido a propriedade ViewStateMode. Porém se manter a propriedades EnableViewState como verdadeira pode alterar a propriedade ViewStateMode para desabilitada. Em resumo trabalhe com a propriedade ViewStateMode. 

A lição tem uma tabela que ilustra como usar essas propriedades de forma mais simples:

Desabilitar a View State de uma página, porém habilitar de um controle especifico:
Page.Enable ViewState: True, Page.ViewState Mode: Disabled, Controle.Enable ViewState: True, Control.ViewState Mode: Enabled

Desabilitar a View State de uma página, e desabilitar de um controle especifico:
Page.Enable ViewState: True, Page.ViewState Mode: Disabled, Controle.Enable ViewState: False, Control.ViewState Mode: Disabled

Habilitar a View State de uma página, porém desabilitar de um controle especifico:
Page.Enable ViewState: True, Page.ViewState Mode: Enabled, Controle.Enable ViewState: False, Control.ViewState Mode: Disabled

Habilitar a View State de uma página, e de um controle especifico:
Page.Enable ViewState: True, Page.ViewState Mode: Enabled, Controle.Enable ViewState: True, Control.ViewState Mode: Enabled

Você pode desabilitar a View State de todo o projeto diretamente no web.config:
<configuration>
<system.web>
<pages enableViewState="false">
</system.web>
</configuration>

Para ler e escrever dados em uma View State é simples:


this.ViewState.Add("MyData", "some data value"); //Escrevendo
string myData = (string)ViewState["MyData"]; //Lendo


Hidden Fields


Não tenho muito o que explicar sobre Hidden Fields, são parecidos com a View State, são campos que armazenam valores, ficam no código html da página porém não são exibidos ao usuário. Só é possível ve-los acessando o código fonte da página.


Cookies


Outra prática comum pra quem já é desenvolvedor web. Cookies armazenam valores no browser do cliente e a cada requisição ao servidor os valores são enviados. A vantagem do uso de cookies sobre o uso de View State e Hidden Fields é que os cookies podem ser acessados de qualquer página desde que esteja no mesmo dominio em que foi criado.


É possível ainda configurar seu tempo de vida e seu dominio. Escrever e ler dados de um cookie é simples:
Response.Cookies.Add(New HttpCookie("userId", userId))

E para ler o valor:
Request.Cookies("userId").Value

Exemplo de código:
// Verifica se o cookie ja existe
if (Request.Cookies["lastVisit"] != null)
    // Encode the cookie in case the cookie contains client-side script
    Label1.Text = Server.HtmlEncode(Request.Cookies["lastVisit"].Value);
else
    Label1.Text = "No value defined";
// Define o valor do cookie
Response.Cookies["lastVisit"].Value = DateTime.Now.ToString();
Response.Cookies["lastVisit"].Expires = DateTime.Now.AddDays(1);

Query Strings

Outra prática comum em qualquer linguagem web. Query String é uso de parâmetros via URL. É formado de um parâmetro e seu valor correspondente. O primeiro parâmetro deve ser informado após o ponto de interrogação ?  os parâmetros seguintes com o &.


Exemplo: http://www.quintelab.com.br/bruno.aspx?id=1&nome=bruno


No exemplo acima o primeiro parâmetro é o ID e o segundo é o NOME. Para ler esses parâmetros informados via QueryString basta:


string id = Request.QueryString["id"].ToString();
string nome = Request.QueryString["nome"].ToString();

Alguns cuidados devem ser tomados, os navedores suportam 2083 caracteres. E fica fácil para qualquer usuário alterar os valores contidos na url. Este caso é muito usado por exemplo para o envio de url via e-mail que quando acessadas irã ser direcionadas já para um produto especifico.

Capítulo 3: Handling Events and Managing State Lição 1: Understanding the ASP.NET Life Cycle and Handling Events

A primeira lição do capítulo 3 explica sobre o ciclo de vida da página e dos controles.

De início a lição começa explicando sobre os eventos mais comuns que são manipulados no arquivo Global.asax:

• Application_Start: É executado quando a aplicação é iniciado no servidor, muito comum quando é feito o acesso do primeiro usuário.
• Application_End: Quando a aplicação é finalizada. Pode ocorrer quando você para a aplicação pelo IIS ou quando é feito o servidor é reiniciado ou desligado.
• Application_Error: Como o nome já explica é executado quando ocorre um erro na aplicação.
• Application_LogRequest: É executado quando é feita uma requisição a aplicação, é usado para gravar informações especificas da requisição.
• Application_PostLogRequest: É executado quando é concluida uma requisição feita ao sistema.

Como uma sessão que é criado por usuário é possível criar uma sessão que é utilizada por toda aplicação. Basta substituir o Session por Application, é como uma sessão, mas ao invés de ser enxergada por um único usuário é enxergada por todos os usuários da aplicação.

Em seguida na lição inicia a explicação do ciclo de vida da página, com certeza a maior dificuldade para programadores de aplicações windows que migram para o ambiente web, pois não estão acostumados com essa situação.

Os eventos mais comuns e em ordem de execução de uma página são os seguintes:

• PreInit: É o primeiro evento que o desenvolvedor pode manipular de uma página, é muito utilizado para definir valores de Master Page ou Temas em tempo de execução. Caso não utilize Master Page é neste evento que você pode criar controles dinamicamente.
• Init: Este evento é executado depois que todos controles foram instanciados, aqui você pode alterar os valores de iniciação dos controles. Caso utilize Master Page é neste evento que deve adicionar os controles dinamicamente.
• InitComplete: Executado quando todas as inicializações estiverem completas.
• PreLoad: Executado antes da viewstate ser carregada e antes de ocorrer o processo de Postback. Necessário quando você precisa que os controles estejam iniciados e antes da viewstate ser restabelecida.
• Load: A página está estável e iniciada. O Evento Load da página é chamada primeiramente, em seguida todos os eventos Load dos controles são executados hierarquicamente.
• LoadComplete: Neste evento todos os controles são carregados.
• PreRender: Este evento ainda permite que alterações finais aos controles. Ocorre depois dos eventos de postback ter ocorridos, e ainda a viewstate não foi salva, ainda permitindo alterações.
• SaveStateComplete: Neste evento a viewstate esta pronta. Qualquer alteração feita neste momento ou depois serão ignoradas. Este evento é util quando você precisa justamente que a viewstate esteja pronta.
• Render: O Render é um método e não um evento, o asp.net chama este método para cada controle. Este método gera os códigos html e todos os outros necessários para exibição da página ao cliente.
• Unload: Este evento é utilizado para liberação de recursos, até pode ser executado manualmente mas é um processo pouco comum.

Após explicar os principais eventos do ciclo de vida da página. A lição explica como criar um controle em tempo de execução. Código simples, única resalva é utilizar o evento Page_PreInit (quando não usar Master Page) ou Page_Init (quando usar Master Page):

protected void Page_PreInit(object sender, EventArgs e)
{
    // Create instances of the controls
    Label FeedbackLabel = new Label();
    TextBox InputTextBox = new TextBox();
    Button SubmitButton = new Button();
    // Assign the control properties
    FeedbackLabel.ID = "FeedbackLabel";
    FeedbackLabel.Text = "Please type your name: ";
    SubmitButton.ID = "SubmitButton";
    SubmitButton.Text = "Submit";
    InputTextBox.ID = "InputTextBox";
    // Create event handlers
    SubmitButton.Click += new System.EventHandler(SubmitButton_Click);
    // Add the controls to a Panel
    Panel1.Controls.Add(FeedbackLabel);
    Panel1.Controls.Add(InputTextBox);
    Panel1.Controls.Add(SubmitButton);
}

protected void SubmitButton_Click(object sender, EventArgs e)
{
    // Create an instance of Button for the existing control
    Button SubmitButton = (Button)sender;
    // Update the text on the Button
    SubmitButton.Text = "Submit again!";
    // Create the Label and TextBox controls
    Label FeedbackLabel = (Label)FindControl("FeedbackLabel");
    TextBox InputTextBox = (TextBox)FindControl("InputTextBox");
    // Update the controls
    FeedbackLabel.Text = string.Format("Hi, {0}", InputTextBox.Text);
}

A lição explica como criar os eventos da página, no caso do vb você deve utilizar os dois ComboBox que estão na parte superior no arquivo de código. E no caso do c#, basta escrever o código, pois a propriedade AutoEventWireup por padrão é true, não necessitando mais nenhuma associação.

Outro processo comum utilizado pelos desenvolvedores e explicados é o PostBack automático. Alguns controles como o botão executam o postback automaticamente quando seu evento é acionado. Mas no caso do evento TextChanged do TextBox por exemplo ele não executa o PostBack automaticamente, é necessário alterar a propriedade AutoPostBack para true, caso não faça isso, o evento TextChanged só será executado quando outro controle executar o PostBack no formulário como por exemplo um clique do botão.

Neste caso como ocorre: O usuário alterou o texto do textBox, nada acontece pois a propriedade esta como false, em seguida o usuário clica no botão. O primeiro evento a ser executado é o TextChanged que estava aguardando um postback ocorrer, em seguida é executado o evento clique do botão.

Se quiser que o TextChanged seja executado assim que o texto seja alterado altere a propriedade AutoPostBack para true.

Assim finaliza esta lição.

Abraços...

Capítulo 2: Using Master Pages, Themes, and Caching!!! Lição 3: Caching

Enfim a última lição do 2º Capítulo, Caching!!

Eu ja tive a oportunidade de trabalhar em projetos que usaram ambos tipos de cache explicados nesta lição. Confesso que achei mais fácil a prática do que a teoria, por isso devo escrever pouco sobre este assunto.

O asp.net facilita o uso de Cache, sendo necessário poucas linhas de código para implentar. Existem dois tipos de cache no asp.net:

• Application caching: representa uma coleção de dados armazenados em memória e que são removidos conforme configurados por tempo ou alguma dependência, ou em ultimo caso quando atingir o limite da memória.
• Page output caching: acredito ser o mais simples e por isso o mais usado, o asp.net permite salvar uma página, ou até mesmo uma parte de uma página como um controle, para reduzir o tempo de resposta quando esta página for solicitada.

Quando se usa o Application caching o cache é dividido por todos na aplicação, pode ser armazenado qualquer coisa, desde uma string, ou até mesmo uma classe populada, datatable e etc, cabe aqui um parênteses, tome cuidado com o tamanho do objeto que colocam em cache devido a memória.

A codificação para trabalhar com o objeto cache é igual a trabalhar com uma sessão, a forma mais simples basta informar a chave e o valor. Ex:

Cache["Greeting"] = "Hello, cache!";
if (Cache["Greeting"] != null)
  Label1.Text = (string)Cache["Greeting"];
else
  Label1.Text = "Hello, world!";

Existe também o método insert que possui mais parâmetros para você configurar seu objeto cache. O método Insert possui os seguintes parâmetros:

• dependencies: é possível configurar uma dependência para manter seu objeto cache. Funciona como uma trigger.
• absoluteExpiration: É um DateTime que define o momento exato que o cache é expirado. Caso não queria definir esta data basta informar: System.Web.Caching.Cache.NoAbsoluteExpiration
• slidingExpiration: é um objeto TimeSpan, onde você informa depois do último acesso quanto tempo irá demorar para seu cache expirar. O contador é zerado toda vez que o cache é acessado. Se não quiser informar, basta: System.Web.Caching.Cache.NoSlidingExpiration
• priority: é o nível de prioridade do cache quando houver a necessidade de remoção de conteúdo, como em um possível estouro de memória, o priority é um enumeration e possui as seguintes opções: Low, BelowNormal, Normal (valor padrão), AboveNormal, High e NotRemovable.

Além dessas opções o objeto cache possui também o evento onRemoveCallback que é disparado quando o objeto é removido do cache.

Page output caching 

Para adicionar uma página ao cache para diminuir a carga ao servidor  melhorar o desempenho do site perando o usuário, é possível colocar suas páginas no cache. Para isso basta adicionar a diretiva @OutputCache em sua página. Caso tenha interesse em armazenar somente uma parte da página, você deve separar esta parte em um Web User Controle e desta forma armazenar este controle no cache.

A diretiva OutputCache possui os seguintes parâmetros:

• Duration: É o número de segundos do cache. É o único parâmetro obrigatório;
• Location
• CacheProfile
• NoStore
• Shared
• VaryByParam
• VaryByControl
• SqlDependency
• VaryByCustom
• VaryByHeader

Por enquanto é isso!!

Abraços...

Capítulo 2: Using Master Pages, Themes, and Caching!!! Lição 2: Using Themes

 Esta lição do capítulo fala especificamente como aplicar temas em suas aplicações web. Fala da possibilidade do uso de CSS também, mas não aprofunda no assunto.

Como já vistos em lições anterires o uso de Temas são para facilitar a manutenção do visual da aplicação, podendo alterar em um único local, e principalmente tornar dinâmico o visual de sua aplicação.

Para começar a criar seu Tema, é bem simples, clique com o botão direito no Solution Explorer, clique em Add Asp.Net Folder, em seguinda clique em Theme. Dentro desta pasta Theme você irá criar seus temas personalizados, cada um dentro da respectiva pasta. Exemplo, dentro da pasta Theme crie a pasta Azul e outra chamada Vermelho.

A seguir basta adicionar dentro de cada pasta, arquivos skins, css e imagens. O ideal é criar um tema por completo e depois sair copiando e colando nos demais temas, só editando o que for especifico de cada tema.

Para aplicar o tema a sua página web ou para toda aplicação, existem dois atributos que podem ser usados, Theme e StyleSheetTheme. Você pode definir essas propriedades diretamente no web.config ou nas páginas que achar necessário:

<pages Theme=”themeName”> ou <pages StyleSheetTheme=”themeName”>

Qual a diferença entre ambos?

Quando se o StyleSheetTheme, essas configurações são aplicadas aos controles antes de aplicar possíveis configurações definidas dirementa no controle, ou seja, por ordem de hierarquia irá prevalecer configurações que estiverem diretamente no controle, caso não tenha nenhuma é aplicado as configuraçoes do Tema.
Como é de se imaginar o uso do atributo Theme é o contrário ele sempre irá prevalecer, substituindo qualquer propriedade definida diremante no controle.

Para criar um Arquivo Skin você deve na pasta do seu tema clicar com o botão direito, então, Add New Item. Em seguinda, selecione Skin File e basta definir o nome do seu skin. Existem dois tipos de skin. Default skins são aplicados a todos os controles daquele tipo, ou seja, se você criar um skin para botões, em todos os botões serão aplicadas as configurações. E Named skins que na verdade é o skin mas com um ID, e para um botão receber essas configurações deve obrigatoriamente informar esta ID, caso contrário não receberá as configurações.

Exemplo de Default skins:

<asp:Button runat="server" BackColor="Red" ForeColor="White" Font-Name="Arial" Font-Size="9px" />

Exemplo de Named skins:


<asp:Label runat="server" SkinId="Title" Font-Size="18px" />


Além de arquivos skin, no seu Tema é possível ainda adicionar imagens e arquivos de folhas de estilos, o famoso CSS. Tudo bem simples e sem segredo.

Como ja explicado para adicionar um Tema basta adicionar os atributos Theme ou StyleSheetTheme no web.config ou em sua página.

É possível também definir uma página ou controle que você não quer que seja aplicado o Tema, basta alterar a propriedade EnableTheming para false: EnableTheming="false".

Essa propriedade pode ser aplicada para toda a página ou para controles especificos.

Para aplicar um tema dinamicamente, ou seja, em tempo de execução, você deve fazer isso no evento Page_PreInit e definir a propriedade Page.Theme.

Protected void Page_PreInit(object sender, EventArgs e)
{
  switch (Session["theme"])
  {
    case "Blue":
      Page.Theme = "BlueTheme";
      break;
    case "Pink":
      Page.Theme = "PinkTheme";
      break;
    default:
      Page.Theme = "GreenTheme";
      break;
  }
}

E assim finaliza mais uma lição.

Abraços...

Capítulo 2: Using Master Pages, Themes, and Caching!!! Lição 1: Using Master Pages

O capítulo 2 começa a falar dos recursos interessantes do .net.

A primeira lição explica sobre o uso de Master Pages, que a primeiro momento é bem simples, mas a parte explicando sobre as propriedades é interessante e com certeza usuários com pouca experiência não devem saber como usar este recurso. Vamos la!!

De inicio para que serve a Master Page? Pra quem ja programo em plataforma windows ou pelo menos ouviu algo, sabe que é possível ter um formulário base, e que todos outros criados herdam este formulário. Normalmente este formulário base possui o menu, uma toolbar e etc. A Master Page segue a mesma idéia para projetos web. Cria-se um layout padrão, onde o mais comum é ter o menu, a logo da empresa e um rodapé, e todas as páginas que usarem esta Master Page, terão este mesmo layout.

A principal idéia é:

• centralizar funcionalidades comuns;
• quando necessário alterar algo, será necessário alterar em um único local;
• desenvolver controles que serão aplicados facilmente em todas as páginas, como um menu;
• e ainda sim, permitir que as páginas que "herdam" esta Master Page possam customizar conforme necessário.

Os arquivos de Master Page são arquivos parecidos com WebForm, mas possuem a extensão .master e uma diretiva na primeira linha do documento <%@ Master no local da diretiva <%@ Page!!

Como fica o resultado para o usuário? O usuário irá acessar a url do formulário normalmente, e quando esta página for renderizada para o usuário será lida a diretiva MasterPageFile que especifica qual a Master Page que a página esta usando, então o conteúdo que estiver na página dentro do controle Content será renderizado junto com a Master Page como uma única página simples para o usuário.

Toda Master Page deve ter o controle ContentPlaceHolder é no "espaço" deste controle no código html que o código das página serão "injetados". Exemplo: irei colocar um ContentPlaceHolder dentro do head e do Body da minha Master Page:

<head runat="server">
<title>Site do quintelab</title>
<asp:ContentPlaceHolder ID="HeadContent" runat="server">
</asp:ContentPlaceHolder>
</head>
<body>
<form runat="server">
<div class="title">
<h1>
Quintelab
</h1>
</div>
<div class="principal">
<asp:ContentPlaceHolder ID="MainContent" runat="server"/>
</div>
<div class="footer">
</div>
</form>
</body>

Repare os dois objetos ContentPlaceHolderé no local deles que o código das demais páginas serão renderizados. Exemplo de uma página que fez referência a esta Master Page:


<%@ Page Language="c#" MasterPageFile="~/Site.master" AutoEventWireup="true" CodeFile="Teste.aspx.cs" Inherits="Teste" %>
<asp:Content ID="HeaderContent" runat="server" ContentPlaceHolderID="HeadContent">
</asp:Content>
<asp:Content ID="BodyContent" runat="server" ContentPlaceHolderID="MainContent">
Aqui meu conteúdo especifico
</asp:Content>

Tudo que estiver dentro dos Content serão renderizados no local dos ContentPlaceHolder.

Vamos aos recursos!! É possível definir no web.config da aplicação ou de uma pasta qual é a Master Page principal, basta:

<pages masterPageFile="MinhaMasterPage.Master" />

Claro será necessário criar nas paginas os controles Contents correspondentes a Master.Page, caso contrário nada irá acontecer.

A parte mais interessante desta lição é como utilizar e customizar Propriedades, Métodos e Controles da Master Page pelas páginas. Um exemplo, um título, você pode colocar uma label em sua Master Page e acessar seu conteúdo através das páginas.

Para isso é necessário ter uma propriedade pública na Master Page, adicionar a declaração @ MasterType nas páginas aspx, e para acessar o valor da propriedade a sintaxe é Master.<NomePropriedade>.

Não tem muito segredo, exemplo:

1º Criando a propriedade pública na Master Page:

public String SharedInfo
{
    get { return (String)Session["SharedInfo"]; }
    set { Session["SharedInfo"] = value; }
}

2º Na página aspx:

<%@ Page Language="c#" MasterPageFile="~/Site.master" AutoEventWireup="true" CodeFile="Login.aspx.cs" Inherits="Login" %>
<%@ MasterType VirtualPath="~/Site.master" %>

3º Acessar o valor da propriedade:

infoLabel.Text = Master.SharedInfo;


Outro recurso interessante, e com certeza irá usar, é o que a lição chama de Nested Master Pages. Que são Master Pages herdadas de outra Master Page. Por exemplo, você pode criar a Master Page Principal.Master onde nela possui a logo da empresa e um rodape. E criar mais duas Master Pages, uma chamada Consulta.Master que herda a Principal e tem particularidades de uma tela de consulta e a Cadastro.Master que também herda da Principal mas possui particularidades de uma tela de cadastro.

Por último e não menos importante, como trocar a Master Page dinamicamente. Mesmo que esta opção exista, você deve na sua página aspx definir na declaração qual é a Master Page que a página utiliza, e claro ambas as Master Page devem ter os mesmos ContentPlaceHolder e as mesmas propriedades. 


Para fazer a troca dinamicamente, é necessário utilizar o evento Page_PreInit e definir a propriedade MasterPageFile. Exemplo:

void Page_PreInit(Object sender, EventArgs e)
{
    MasterPageFile = "~/MinhaMasterDinamica.master";
}

E desta forma se encerra a 1º Lição do Capítulo 2. Muito útil com certeza.

Abraços!!

1º Capítulo, 3ª Lição - Working with Web Configuration Files

Enfim chegei a 3ª e última lição do 1º Capítulo. Esta lição fala sobre arquivos de configuração de aplicações usando o .net 4.

Particularmente achei muito simples e útil para o dia a dia, a lição fala exclusivamente sobre a hierarquia dos arquivos de configuração, os famosos .config

O mais conhecido de todos os desenvolvedores com certeza é o web.config que é criado automaticamente pelo visual studio quando criamos um projeto web. Mas não temos só esse arquivo de configuração.

O arquivo de configuração Master (Pai de todos) é o machine.config que pode ser encontrado no seguinte caminho (%System Root%\Microsoft.NET\Framework\
\CONFIG\Machine.config). As definições de configuração que estão no machine.config serão válidas e aplicadas para qualquer aplicação que use o .net neste servidor, seja ela web, windows, class library ou console application.

Seguindo a hierarquia abaixo do machine.config tem o web.config root. Este web.config contém definições que são aplicadas para todos websites do servidor. Se por acaso ficou em dúvida sobre a definição de web site, quando o IIS é instalado ele cria um único WebSite que é o WebSite Padrão, ou seja, esse web.config root irá conter definições para todos os WebSites que estiverem neste servidor. Este arquivo pode ser encontrado em: (%SystemRoot%\Microsoft.NET\Framework\\CONFIG\Web.config)

Após o web.config root, temos o web.config do website que é especifico de cada website, como eu disse no parágrafo acima, podemos ter mais de um hospedado, então tendo um web.config para cada um podemos especificar algumas definições.

Enfim chegamos ao tradicional web.config da aplicação que é o web.config que você tem ae no seu visual studio e que contém as definições que mais alteramos com por exemplo a conexão com banco de dados.

E é possível ainda criar um web.config para cada pasta de sua aplicação, isso é mais comum em grandes aplicações, onde é necessário definir regras e configurações especificas em algumas pastas.

Basicamente o que a lição mostra é isso. Como tudo isso funciona? Da mesma forma que escrevi, hierarquicamente. O .net começa aplicando as definições do machine.config e vem passando por cada arquivo .config aplicando o que for necessário.

Assim finalização o 1º Capítulo.