quinta-feira, 31 de março de 2011

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!!

    terça-feira, 22 de março de 2011

    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.

    domingo, 20 de março de 2011

    1º Capítulo, 2ª Lição - Creating a Website and Adding New Webpages

    A segunda lição do primeiro capítulo continua simples como a primeira lição para quem já trabalha com o Visual Studio. Esta lição mostra como criar web sites/web applications no visual studio e as opções que você escolher neste momento, e também como adicionar uma nova página aspx ao seu projeto.

    Na criação de um projeto web o visual studio te da algumas opções como:

    Qual linguagem usar, normalmente:
    • Visual Basic
    • Visual C#
    E a opção de conexão do visual studio com o projeto que é o grande foco da lição:
    • File system: Como o nome mostra, sistema de arquivos simples, você pode armazenar os arquivos tanto localmente, como em um servidor remoto. A lição explica o uso do recurso do WebDAV caso queria usar um servidor remoto. Até onde eu vi pouco usado pela comunidade, com certeza o file system local é o mais comum.
    • FTP: Simples como o nome mostra é quando você trabalha conectado em um ftp que esta em um servidor remoto. Esta opção não tem muito segredo e é a menos explicada na lição. Cuidado com a segurança pois os arquivos de código estarão expostos no seu servidor. O IIS bloqueia o acesso via browser. Mas lembre-se que o FTP esta exposto.
    • HTTP: Para trabalhar com esta forma de conexão, você precisará do WebDAV Publishing, caso seja Windows Server 2008 R2, ou se for uma versão inferior poderá usar o Microsoft Front Page Server Extensions 2002. A lição explica como instalar os recursos do IIS necessários para trabalhar desta forma. E após instalados basta criar um website ou um diretório virtual para sua aplicação.
    Depois de mostrar as configurações disponíveis no Visual Studio, a lição lista e explica as pastas e os arquivos criados quando você usa o Template de Projetos Web do Visual Studio, como por exemplo, as pastas Account, App_Data e Scripts, e arquivos como Default.aspx, Global.asax e outros que são criados automaticamente.

    Esta lição também fala sobre as duas opções de criar uma página aspx:
    • Single-File: É quando o código de programação, seja visual basic ou visual c# ficam no mesmo arquivo do código html.
    • Code-behind: Com certeza a forma mais usada e recomendada, quando fica separado em arquivos distintos o código de programação que roda do lado servidor, e o lado de código html e outros scripts que rodam do lado do cliente.
    Outro ponto brevemente falado é sobre a forma de compilação dos projetos.

    Na primeira o desenvolvedor pode simplesmente copiar os arquivos para o servidor, onde a principal vantagem é não ter que compilar toda a aplicação quando quiser fazer a instalação, e quando ouver mudanças subir um único arquivo será possível. E a grande desvantagem é que a primeira vez que a página for acessada ela terá que ser compilada, gerando um tempo de espera para o usuário, o que não é nada bom.

    E a outra opção, acredito ser a mais usada e correta é compilar sua aplicação. A desvantagem é justamente a vantagem do item anterior, toda vez que ocorrer uma mudança toda a aplicação deve ser compilada. E a vantagem é que as páginas carregarão mais rápido para o usuário, além de não ter que subir código fonte para o servidor de produção, o código fica compilado em dll, se tornando assim mais seguro.

    Por enquanto é isso!!

    Abraços...

    quarta-feira, 16 de março de 2011

    Rumo a certificação, 1º capítulo

    Mais uma vez vou me arriscar a começar os estudos para a certificação em asp.net da Microsoft. E conforme for lendo, vou ir tentando escrever aqui sobre os capítulos do livro:
    Microsoft Press MCTS Self Paced Training Kit Exam 70-515

    O primeiro capitulo é só uma introdução ao mundo web, como o título diz:
    Introducing ASP.NET 4

    A primeira lição é uma explicação sobre a forma de comunicação na web, qualquer programador web hoje sabe o que esta escrito neste lição, são protocolos usados entre a comunicação cliente - servidor, código de retornos do servidor e etc...

    Esta lição se foca principalmente em dois pontos:

    1º Ponto, mostrar e explicar os principais códigos de retorno do servidor ao navegador, o exemplo mais clássico e conhecido é o código 404 de Not Found, na lição é possível encontrar uma tabela com esse códigos e suas devidas descrição.

    O 2º Ponto, e acredito o mais importante é a diferente entre a forma de enviar requisições ao servidor, usando Get ou Post.

    Como explicado na lição e acredito que muitos saibam quando usamos o Get as informações são passadas pela url via querystring. Isso se torna uma vantagem para facilitar buscas e criar links personalidados para sua aplicação, mas pode e com certeza será um transtorno para evitar que informações sejam modificadas através da URL, podendo até mesmo comprometer sua aplicação.

    Sem dúvida a melhor forma de enviar requisições ao servidor é usando o comando POST onde os dados são enviados pelo corpo da mensagem, de forma transparante para o usuário.

    No último parágrafo desta lição cita-se o IsPostBack, até o momento irrelevante, mas acredito que mais pra frente irei ler sobre o ciclo de vida de um formulário e principalmente de uma página aspx.