msdn24_capa.jpg

Clique aqui para ler todos os artigos desta edição

 

Personalização de Interface de Usuário no ASP.NET

 

Sempre que vamos desenvolver algum novo sistema precisamos de algumas funcionalidades que são iguais àquelas que já desenvolvemos um dia ou então com algumas pequenas modificações. As vezes, por serem sistemas sob encomenda, sempre acabamos reinventando a roda ou senão aplicamos o velho processo de herança “.........” e alteramos algumas coisas para personalizar o produto final. Mas, porque não usarmos os esforços para desenvolver as funcionalidades específicas de cada solução e parametrizamos, reutilizamos e/ou estendemos o que é repetitivo? Com isso em mente estaremos avaliando uma alternativa simples de implementar este tipo de funcionalidade.

 

Projeto

Para implementar as funcionalidades descritas aqui, crie um projeto ASP.NET WebApplication chamado SkinsMSDN, usando como linguagem o Visual C#. Nas propriedades do projeto altere as configurações do Assembly Name e Default Namespace, conforme a Figura 1. Esta alteração se faz necessária devido às configurações posteriores que iremos fazer.

 

image001.gif

Figura 1. Painel de propriedades do projeto.

 

Por uma questão de organização, iremos criar algumas pastas dentro do projeto (conforme a Figura 2). Note que é importante mantermos a mesma nomenclatura aqui apresentada.

 

image002.gif

Figura 2. Estrutura de Pastas necessárias para a aplicação.

 

Configuração de Módulos

Como o objetivo é criar um módulo independente e facilmente acoplável a qualquer solução, é preciso configurar as informações necessárias para que seja possível a utilização desta facilidade oferecida pelo Framework. Neste ponto estaremos fazendo uso do httpModules que são chamados antes e depois que um handler é executado, e nos habilita interceptar, participar ou modificar cada requisição. Esta funcionalidade implementa a interface IHttpModule, que está no namespace System.Web. Para ativarmos esta funcionalidade precisaremos de duas coisas:

1 - Configurar o Web.Config direcionando a execução do handler, conforme código:

 

Listagem 1. Classe Web.Config

...

  

    

    

  

...

 

2 - Criar uma classe (Listagem 2) que atenda ao requisito de implementação da interface, e que esteja configurada no Web.Config. Esta classe deve ser criada na pasta ModuleHandler, com o nome ModuleHandler:

 

Listagem 2. Classe ModuleHandler.cs

using System;

using System.Web;

using System.Collections;

 

namespace MSDNMag.ModuleHandler

{

            ///

            /// Gerenciador do módulo

            ///

            public class ModuleHandler : IHttpModule

            {

                        public ModuleHandler(){}

 

                        public void Init(HttpApplication context)

                        {

                                   /* Configura o controle de início de requisição */

                                   context.BeginRequest +=new

                                                           EventHandler(moduleHandler_BeginRequest);

                        }

 

                        public void Dispose(){}

 

                        private void moduleHandler_BeginRequest(object sender, EventArgs e)

                        {

                                   /* Associa na requisição corrente os objetos que deverão ser

                                    * carregados pela página principal */

                                   ArrayList pageComponents = new ArrayList();

                                   pageComponents.Add("MSDNMag.ClassControls.EditPeople");

                                   HttpContext.Current.Items["PageComponents"] = pageComponents;

                        }

            }

}

 

Até aqui vimos uma boa alternativa para associarmos módulos às aplicações, sem termos que ficar juntando suas partes em um único (e grande) assembly. É claro que para que isso funcione de uma maneira adequada é preciso que exista um bom projeto de software que dê as linhas comuns para a implementação e integração de seus módulos, mas isto não é o foco deste artigo.

Neste artigo estamos abordando uma visão simplista dos módulos HTTP, mas avaliando um pouco mais de perto essa funcionalidade, perceberemos que é possível desenvolver coisas interessantes aqui, como por exemplo, cuidar dos processos de autenticação para o módulo, direitos e acessos, através da assinatura do evento  AuthenticateRequest.

 

O ancestral dos WebControls

Depois de criado o gestor do módulo, vamos para a criação do ancestral das classes WebControls (a classe SkinControlMaster deve ser criada na pasta Ancestor). A Listagem 3 mostra no próprio código comentários explicativos referentes ao que está sendo feito na classe.

 

Listagem 3. Classe SkinControlMaster.cs

using System;

using System.Configuration;

using System.Data;

using System.IO;

using System.Web;

using System.Web.UI;

using System.Web.UI.WebControls;

 

namespace MSDNMag.Ancestor

{

            /// Classe ancestral da engine dos componentes que suportam skin

            /// Esta classe é definida como abstrata uma vez que assina métodos que são

            /// implementados em seus descendentes.

            /// Classes / Interfaces / Atributos

            /// INamingContainer:

            ///      Qualquer controle que impelemente essa interface cria um novo namespace

            ///      onde todos os ID's dos controles filhos são garantidos e são únicos dentro

            ///      de uma aplicação.

            ///      A funcionalidade provida por esta interface permite nomenclatura única

            ///      de instâncias de controles de servidor gerados dinamicamente dentro de

...

Quer ler esse conteúdo completo? Tenha acesso completo