Usando controles do servidor ASP.NET em aplicativos Web Parts

Artigo
10/15/2014

Em um aplicativo Web Parts, a principal interface do usuário (IU) consiste em controles de servidor ASP.NET que residem em zonas--regiões de uma página da Web que têm um interface do usuário em comum e são criadas por um tipo de controle composto derivados da classe WebPartZoneBase.Os recursos desses controles de servidor que formam a interface do usuário primária de um aplicativo Web Parts são definidos na classe base WebPart, mas você não está limitado a usar os controles que derivam dessa classe.Você também pode usar qualquer controle de servidor ASP.NET, controle de usuário ou controle de servidor personalizado padrões.Este tópico aborda algumas questões sobre como usar os controles de servidor em aplicativos Web Parts quando os controles não herdam da classe WebPart.

Criando controles Web Parts em tempo de execução

Para os vários tipos de controles de servidor que não herdam da classe WebPart, o conjunto de controles de Web Parts fornece um mecanismo que permite que eles para participem de aplicativos Web Parts e possuam os mesmos recursos como um controle derivado da classe WebPart.Isso não requer nenhuma ação especial por desenvolvedores; tudo que é necessário é adicionar um controle de servidor a uma zona WebPartZoneBase.Quando um página da Web é compilada, qualquer controle de servidor que reside em uma zona e não herda da classe WebPart é empacotado automaticamente com uma instância da classe GenericWebPart e se torna um controle filho dessa instância.Porque a classe GenericWebPart herda da classe WebPart, o controle de servidor está ativado com a funcionalidade total de um controle WebPart.Basicamente, adicionando controles de servidor que não herdam da classe WebPart a uma zona WebPartZoneBase, os desenvolvedores habilitam os controles para se tornar controles WebPart em tempo de execução.

Observação:
Assim como você pode usar os controles do servidor de aplicativos Web Parts, você também pode usar controles WebPart fora de aplicativos Web Parts.Se você adicionar um controle que herda da classe WebPart para uma página fora de uma zona, ele funciona como um controle de servidor normal e simplesmente perde suas capacidades Web Parts.

Adicionando controles de servidor ASP.NET em zonas

Quando você adiciona controles de servidor ASP.NET, controles de usuário ou controles personalizados a uma zona WebPartZoneBase, não são necessárias técnicas especiais ou declarações na página.Você pode adicioná-los a uma zona da mesma forma que você normalmente adicionaria controles de uma página da Web: declarativamente (no formato de persistência do página), ou programaticamente.Além disso, você pode usar o recurso do catálogo de Web Parts, que permite você a adicionar controles de servidor de um catálogo a partir da qual os usuários podem selecionar e adicionar os controles para a página em tempo de execução.Para obter mais informações, consulte os controles DeclarativeCatalogPart e ImportCatalogPart.

Se você adicionar um controle de servidor a uma zona por meio de programação, a abordagem recomendada é adicioná-lo usando o método AddWebPart do controle WebPartManager.

Ao adicionar controles de servidor que não são controles WebPart declarativamente a uma zona, se você usar uma ferramenta de design visual, como Microsoft Visual Studio 2005, você não verá propriedades WebPart e membros no painel de propriedades ou do IntelliSense.Para obter mais informações, consulte a seção a seguir que descreve quando usar controles WebPart versus usar outros controles de servidor.

Decidir quando usar as diferentes opções de controle do servidor

Como você pode usar qualquer tipo de controle de servidor em um aplicativo Web Parts, você pode imaginar se há qualquer razão para criar um controle que é derivado da classe WebPart.

Os principais fatores que você deve considerar são as vantagens de adaptar controles de servidor preexistentes em vez de criar novos por derivação da classe WebPart.As diretrizes a seguir podem ajudar na sua decisão.

Usando controles do servidor

Em muitos casos, a opção preferencial para criar controles de Web Parts é usar um controle de servidor ASP.NET, um controle de usuário ou um controle personalizado, particularmente se os controles já existirem.Você não perderá qualquer funcionalidade Web Parts em tempo de execução quando você usa esses tipos de controles de servidor, e você tem muitas vantagens, como a capacidade de reutilizar código existente e a capacidade de aumentar seu conhecimento do desenvolvimento de controle e aplicá-lo aos aplicativos Web Parts.

Você também pode fazer os vários controles de servidor se comportam de forma idêntica a controles WebPart verdadeiros implementando várias interfaces que a classe WebPart implementa.Eles incluem:

A interface IWebActionable.Se você implementar essa interface, você será capaz de adicionar verbos personalizados (ações comuns que os usuários podem executar em um controle na interface do usuário, como Minimizar, Fechar, ou Editar) no menu de verbos do seu controle.
A interface IWebEditable.Se você implementar essa interface, você pode associar controles EditorPart personalizados com o controle de servidor, permitindo que os usuários editem propriedades personalizadas especificadas e o comportamento no controle em tempo de execução.
A interface IWebPart.Se você implementar essa interface, o controle terá um número de propriedades de um controle WebPart verdadeiro que é herdada da classe Part, que dá a ele a mesma aparência de um controle WebPart, mesmo em tempo de design.

A derivação de WebPart

A principal vantagem de criar um controle pelo derivar da classe WebPart é que você obtém controle total sobre o comportamento específico do Web_Parts.

Um exemplo disso ocorre se um desenvolvedor de controle deseja alterar o comportamento em tempo de execução de um controle, e então redistribui-lo aos usuários.Um desenvolvedor pode substituir uma das propriedades virtuais da classe WebPart--como AllowClose--e torná-lo uma propriedade somente leitura que sempre retorna false.Isso impede que o controle nunca seja fechado, e usuários do controle são limitados a esse comportamento.

Um segundo exemplo no qual você pode beneficiar por herança da classe WebPart relaciona-se ao comportamento de tempo de design.Em um controle WebPart, todos os membros WebPart expostos são visíveis para desenvolvedores de página no tempo de design por meio do IntelliSense (se eles usarem uma ferramenta de design visual como o Microsoft Visual Studio 2005), para que eles possam trabalhar com as propriedades no modo declarativo e no painel Propriedades.Por outro lado, se você declarar controles de servidor em uma zona em tempo de design, e eles não são controles WebPart, você não puder ver os membros que são específicos para a classe WebPart (embora você ainda pode declará-los) em IntelliSense ou no painel Propriedades.Isso porque em tempo de design, um controle de servidor comum foi ainda não quebrada com um objeto GenericWebPart, para que ele não tenha os recursos WebPart que terá em tempo de execução.Embora você possa ativar os controles do servidor para procurar e agir como controles WebPart implementando as interfaces listadas acima, geralmente é mais simples um controle WebPart.Desenvolvedores de controle e fornecedores que criam pacotes de controles podem se beneficiar derivando da classe WebPart para que eles possam fornecer recursos de tempo de design mais sofisticados para seus controles.

Conclusões

Em conclusão, se você não precisar substituir as propriedades padrões do controle, talvez seja mais fácil de usar os controles de servidor pré-existente e torná-los parte do controle WebPart.

Se você optar por criar um controle WebPart personalizado, a seguir são as propriedades que você pode possivelmente substituir:

Controles de usuário como os controles WebPart

Controles de usuário são uma opção poderosa para desenvolvedores do ASP.NET, pois eles permitem aos desenvolvedores criar rapidamente um interface do usuário complexa para um controle usando a mesma sintaxe declarativa usada em páginas da Web.Eles também fornecem uma maneira conveniente de particionar e reutilizar o código em várias páginas.Como o controle de servidor ASP.NET, os controles de usuário são também uma opção excelente para uso em aplicativos Web Parts.Controles de usuário podem ser adicionados diretamente a uma zona WebPartZoneBase, e eles funcionarão como controles WebPart em tempo de execução, conforme descrito acima.Eles podem também ser usados com o recurso do catálogo Web Parts, ou como controles que podem ser importados, ou para empacotar um conjunto de outros controles de servidor que os usuários podem selecionar e adicionar a uma página (para obter mais informações, consulte a propriedade WebPartsListUserControlPath).

Observação importante:
Você deve estar ciente de que o cache de saída ASP.NET é desabilitado em controles de usuário que estão sendo usados como controles WebPart em tempo de execução.O conjunto de controles de Web Parts exige que um controle esteja na árvore de controle para cada solicitação para uma página.Isso é necessário para alguns recursos Web Parts, como personalização (para obter mais informações, consulte Visão geral sobre personalização de Web Parts), para funcionar.Em solicitações onde um controle de usuário é armazenado em cache (para obter mais informações, consulte a diretiva @ OutputCache), ele não é adicionado à árvore de controle.Por esse motivo, o cache de saída é incompatível com recursos Web Parts e não funciona com controles de usuário que estão funcionando como controles WebPart em um aplicativo Web Parts.

Você deve estar ciente de que o cache de saída ASP.NET é desabilitado em controles de usuário que estão sendo usados como controles WebPart em tempo de execução.O conjunto de controles de Web Parts exige que um controle esteja na árvore de controle para cada solicitação para uma página.Isso é necessário para alguns recursos Web Parts, como personalização (para obter mais informações, consulte Visão geral sobre personalização de Web Parts), para funcionar.Em solicitações onde um controle de usuário é armazenado em cache (para obter mais informações, consulte a diretiva @ OutputCache), ele não é adicionado à árvore de controle.Por esse motivo, o cache de saída é incompatível com recursos Web Parts e não funciona com controles de usuário que estão funcionando como controles WebPart em um aplicativo Web Parts.