Com a disseminação cada vez maior da internet, as aplicações Web tendem cada vez mais serem customizadas para atender um determinado usuário/cenário. Os usuários estão a cada dia mais exigentes e com isso nossas aplicações devem estar preparadas para isso. Essas customizações vão desde o que o usuário quer realmente ver até em que posição da tela ele quer que essa informação apareça. Já há vários sites que possibilitam essas customizações e um dos mais conhecidos é o já citado Windows Live Spaces, que fornece-nos uma gama de funcionalidades a nível de adição de conteúdo, customização das informações e aparência.

Na versão 2.0 do ASP.NET a Microsoft introduziu novos controles, denominados WebParts. A intenção é possibilitar a nós desenvolvedores criarmos aplicações mais customizavéis e, conseqüentemente, mais agradáveis aos nossos consumidores. Esses controles estão contidos dentro da ToolBox do Visual Studio .NET 2005 e sua respectivas classes e membros (enumeradores, estruturas, etc) constam dentro do namespace System.Web.UI.WebControls.WebParts.

Arquitetura das Classes

Antes de começarmos a analisar os controles já fornecidos pelo ASP.NET, vamos primeiramente entender como funciona a hierarquia das classes que provêm as funcionalidades das WebParts. Existem duas formas de estarmos criando uma WebPart. Você pode utilizar qualquer controle ASP.NET (TextBox, Calendar, User Control, GridView, etc.) como uma WebPart ou, se desejar um controle ainda mais customizado, pode herdar da classe abstrata chamada WebPart ou até mesmo implementar (direta ou indiretamente) a interface IWebPart.

Quando utilizamos algum controle ASP.NET como uma WebPart (que por sua vez não herda a classe WebPart e nem implementa a IWebPart), ele é encapsulado por uma classe denominada GenericWebPart que, por sua vez, implementa diretamente a interface IWebPart. Essa classe serve como um wrapper para o seu controle ASP.NET, provendo a ele todas as funcionalidades de uma WebParts, funcionalidades que veremos mais adiante. Para ilustramos melhor essa hierarquia, vejamos a imagem abaixo:

Analisando a imagem acima podemos ver a interface IWebPart, que nos fornece várias propriedades que definem algumas características de UI (User Interface) comuns entre todas as WebParts. Através da listagem abaixo será possível entender qual a finalidade de cada uma dessas propriedades:

Ainda analisando a imagem acima, podemos notar três outras classes: Part, WebPart e GenericWebPart. Essas classes são extremamente importantes dentro da arquitetura do Framework de WebParts e veremos a utilidade de cada uma delas abaixo.

A classe Part define propriedades comuns para todos os controles do tipo parts que tem uma aparência consistente, fornecendo propriedades para a customização da part dentro da página. Para exemplificar, podemos citar dois tipos de parts: a WebPart, que falaremos mais abaixo e o controle EditorPart, que fornece-nos uma UI para modificar (personalizar) uma determinada WebPart.

Já a classe WebPart serve como classe base para todos os controles WebParts, pois herda diretamente da classe Part, adicionando ainda funcionalidades para criar conexões entre WebParts, personalização e interações com o usuário. Se quiser criar uma WebPart customizada e fazer uso de todas as funcionalidades fornecidas pelas WebParts, então é desta classe que você deverá herdar e customizar de acordo com a sua necessidade. E, quando herdá-la, atente-se a sobrescrever o método RenderContents, que é o responsável pela exibição do conteúdo que a sua WebPart irá apresentar dentro da página. O trecho de código abaixo mostra um pequeno exemplo de como implementar essa classe concreta:

using System;
using System.Web.UI;
using System.Web.UI.WebControls.WebParts;

public class CustomWebPart : WebPart
{
    public CustomWebPart()
    {
        this.Title = "Minha WebPart";
    }

    protected override void RenderContents(HtmlTextWriter writer)
    {
        writer.Write("O conteúdo deve ser colocado aqui!");
    }
}

Finalmente a classe GenericWebPart, como já citamos anteriormente, herda diretamente da classe WebPart e serve como wrapper para controles que não tem suporte intrínsico as funcionalidades de WebParts, comportando-se como uma verdadeira WebPart em runtime. Como a utilidade desta classe é servir de wrapper para o controle, ela nunca será declarada dentro do HTML da página ASPX. Como essa classe só existirá em runtime, é possível acessá-la através de um método chamado GetGenericWebPart da classe WebPartManager. Esta, por sua vez, possui uma propriedade chamada ChildControl, que retorna uma referência ao controle que foi encapsulado pela GenericWebPart.

Controles de WebParts

Antes de efetivamente entrarmos na definição dos controles, é importante termos em mente um conceito bastante importante: as Zonas. As zonas são basicamente o local físico dentro da página onde podemos colocar uma ou mais WebParts. Como era de se esperar, vamos falar um pouco sobre a hierarquia de zonas que o Framework de WebParts nos fornece. Para isso, vejamos a figura abaixo:

Para iniciarmos nossa análise, iniciaremos com a classe WebZone. Essa classe abstrata provê grande parte das funcionalidades para os controles que servem como containers, ou seja, para os controles (parts) que estão contidos dentro da zona, sendo a classe base para todas as zonas fornecidas pelo Framework de WebParts. Isso inclui controles Web Parts, controles de servidor e User Controls. Como já era de se esperar, uma zona pode armazenar vários controles internamente, já que o mesmo herda diretamente da classe CompositeControl e a sua renderização é gerada em tabelas HTML. Como essas zonas permitem a configuração da aparência das mesmas, logo, qualquer WebPart colocada dentro dela herdará essas configurações.

Derivadas desta classe, existem dois tipos: WebPartZoneBase e ToolZone. A primeira delas, WebPartZoneBase, além de herdar todas as funcionalidades da classe WebZone, adiciona código cliente (Javascript) para permitir o Drag and Drop das WebParts contidas dentro da zona, coloca em funcionamento os verbos (veremos mais tarde a respeito), e outros detalhes a nível de aparência, como por exemplo bordas e menus. Um detalhe importante é que essa classe fornece duas propriedades interessantes; a primeira delas chamanda WebParts do tipo WebPartCollection, que retorna uma coleção de objetos do tipo WebPart, representando todas as WebParts que estão contidas dentro daquela zona; a segunda, LayoutOrientation, é onde especificamos em que sentido as WebParts serão posicionadas dentro da zona, ou seja, Vertical ou Horizontal. Já a outra classe, ToolZone, tem a finalidade de servir como classe base para as zonas que somente aparecerão em determinados modos de visualização, contendo controles especiais que permitem os usuários modificar a aparência e propriedades que foram herdadas, e assim criar zonas mais customizadas. Ainda analisando o diagrama de classes, podemos ver que da classe base WebZone surgem algumas outras zonas, como por exemplo EditorZone, CatalogZone, ConnectionsZone e WebPartZone, mas estas já são controles que estão dentro da ToolBox do Visual Studio .NET 2005, queveremos mais abaixo.

Para ilustrar as zonas e as WebParts, onde e como elas se encaixam, a imagem abaixo mostra no primeiro quadro, as seções da página que contém zonas disponíveis que permitem o drag-and-drop de WebParts. Já o segundo quadro exibe as mesmas zonas, só que agora com uma WebPart diferente dentro de cada zona. Vale lembrar que nada impede de termos todas as WebParts dentro de uma única zona e, como já podemos deduzir, é necessário que nossa página tenha, no mínimo, uma zona para que possa armazenar as WebParts.

Agora que já vimos como é a hierarquia e estrutura das classes que fornecem as WebParts e WebZones, vamos analisar os controles que o próprio ASP.NET nos fornece para usarmos dentro da página ASPX. Os controles serão aqui apresentados, porém veremos o uso deles no decorrer deste artigo, analisando detalhadamente cada um deles quando forem realmente utilizados.

 WebParts.zip (293.75 kb)