Visão geral sobre personalização de Web Parts

Visão geral sobre personalização de Web Parts

Em certas aplicações da Web, você pode querer permitir que os usuários modifiquem, ou personalizem a interface de usuário e o comportamento do aplicativo. O conjunto de controles Web Parts ASP.NET fornece essa funcionalidade em um des seus recursos principais, personalização.A personalização permite que as propriedades e o estado dos controles Web Parts sejam salvos para armazenamento de longo prazo e não apenas sejam ligados a uma sessão determinada do navegador.

Personalização permite criar propriedades para controles de Web Parts que têm várias características únicas. Propriedades personalizáveis ​​são:

  • Maneira de vincular a identidade de um usuário específico e uma página web. Configurações de cada usuário para os controles personalizáveis ​​em cada página podem ser salvas em dados de personalização. Esses dados permitem que os usuários modifiquem a interface do usuário em uma página da Web e salvar suas preferências individuais.

  • Vida-Longa Configurações personalizadas não estão vinculadas a uma única sessão do navegador. Porque elas são armazenadas no armazenamento de longo prazo, o aplicativo pode recuperar as configurações do usuário cada vez que o usuário visitar uma página específica.

    Personalização utiliza um banco de dados de serviços de aplicativos ASP.NET para armazenar os dados de personalização. Por padrão, o ASP.NET cria este banco de dados automaticamente em uma subpasta chamada "app_data" quando uma aplicação ASP.NET primeiro usa personalização ou um dos outros serviços de aplicações, tais como papéis, membros ou perfis. Também por padrão, o ASP.NET cria o banco de dados como um único arquivo de banco de dados SQL Server Express que contém o esquema de banco de dados para todos os serviços de aplicativos. Usando o arquivo Web.config, você pode configurar seu aplicativo para que um arquivo de banco de dados separado seja criado para a personalização. Além disso, no arquivo Web.config, você pode especificar um banco de dados SQL Server para armazenar os dados em vez de usar o arquivo de banco de dados SQL Server Express padrão de serviços de aplicativos.

  • Persistência através de uma camada de provedor. O mecanismo para armazenar e recuperar dados de personalização consiste de um componente fornecedor e um armazenamento de dados. ASP.NET inclui um provedor SQL padrão Microsoft e banco de dados. Você também pode criar um provedor personalizado e configurá-lo para usar qualquer armazenamento de dados.

  • Declarativo em qualquer controle de Web Parts. Quando você estiver desenvolvendo um controle personalizado, você pode adicionar o atributo Personalizable no código para ativar uma propriedade específica em qualquer controle de Web Parts para personalização.Além disso, para controles personalizados derivados da classe WebPart, isso também se aplica a controles de servidor ASP.NET, controles de servidor personalizados ou controles de usuário, desde que eles possam ser usados como controles de Web Parts.

    ObservaçãoObservação:

    É importante reconhecer que as propriedades comuns são tratados de forma diferente em que eles não podem ser mantidos como propriedades personalizáveis​​. Se você adicionar um controle WebPart ou outros controles de servidor a uma zona WebPartZoneBase por meio de programação, e você tentar definir suas propriedades não personalizáveis por meio de programação (por exemplo, se você definir a propriedade Text em um controle Label), as propriedades são redefinidas para seus valores padrão depois que os controles são adicionados, porque não há nenhuma maneira para que esses valores de propriedade sejam persistidos no armazenamento de personalização a longo prazo. Para persistir as propriedades no armazenamento de longo prazo, elas devem ser marcadas com o atributo Personalizable no código fonte. Alternativamente, se você quiser manter as propriedades somente entre as solicitações dentro da mesma sessão do navegador (mas não no armazenamento de longo prazo), você pode usar o estado de exibição.

Personalização contrasta de várias maneiras com as outras técnicas de ASP.NET para persistir dados de estado de um aplicativo Web:

  • A personalização é uma característica das Web Parts. Você não pode usar personalização por si só. Para usar Personalização, você deve usar os controles em um WebPartZone para que eles tenham funcionalidades Web Parts.

    ObservaçãoObservação:

    Qualquer controle ASP.NET de servidor, controle personalizado, ou controle de usuário pode ser usado como um controle Web Parts para tirar proveito de personalização.

  • Personalização é diferente do estado de exibição. O estado de exibição e personalização persistem os dados do estado dos controles, mas os dados de estado de exibição persistem apenas durante a sessão atual do navegador, enquanto que os dados de personalização são de longa duração.

  • Personalização é diferente dos perfis. Personalização armazena dados de estado específicos do usuário para o controle de apenas uma página da Web em particular. A informação que se relaciona com o usuário como uma pessoa, e que se destina a ser usado em várias páginas em um aplicativo da Web (como informações de conta em um aplicativo de carrinho de compras), deve ser mantido em um perfil. Para mais informações, veja Visão geral sobre propriedades de perfil do ASP.NET.

Quando você usa a personalização com controles de Web Parts, você deve compreender vários conceitos que afetam o funcionamento dela.

O primeiro conceito é o escopo de personalização da página. Escopo de personalização da página é a gama de usuários para que as alterações de personalização de uma página pode aplicar. Em um determinado momento, uma página de Web Parts pode estar em um dos dois possíveis escopos de personalização, Shared ou User. No âmbito compartilhada, todas as alterações de personalização da página aplicam-se a todos os utilizadores, no âmbito do usuário, as alterações de personalização da página aplicam-se apenas para o usuário atual.

Um segundo e relacionados conceito é a visibilidade de controle. Visibilidade de controle determina se um determinado controle é visível para um usuário individual ou para todos os usuários. Cada controle WebPart em uma página é um controle compartilhado, visível para todos os usuários da página, ou um controle per-user (por usuário), visível somente para um usuário individual. A visibilidade é determinada pela forma como um controle é adicionado a uma página. Se um controle é adicionado, declarando-o na marcação de uma página da Web (um controle estático), é sempre um controle compartilhado. Se um controle é adicionado pelo código do aplicativo ou por um usuário selecionando-o a partir de um catálogo de controles (um controle dinâmico), a visibilidade é determinado pelo escopo de personalização atual da página. Se a página está no escopo Shared, um controle adicionado dinamicamente é compartilhado, e se a página está no escopo User, o controle é um controle por usuário.

Um terceiro conceito importante é o escopo de propriedade. Quando você cria uma propriedade personalizável em um controle usando o atributo Personalizable no código-fonte, você pode definir o escopo de personalização para a propriedade como Shared ou User (User é o escopo padrão). Isso proporciona um controle detalhado sobre quais propriedades em um controle pode ser personalizado por todos os usuários, e que só pode ser personalizado por usuários autorizados quando o escopo de página é Shared.

Tomados em conjunto, estes conceitos de escopo página de personalização, a visibilidade de controle e alcance propriedade de personalização criar a gama de opções para como os controles Web Parts podem ser visualizados e personalizados pelos usuários. A tabela a seguir resume como controles Web Parts se comportam quando os usuários personalizá-los nos diversos âmbitos.

Visibilidade do Controle

Página no escopo Shared

Página no escopo User

controle compartilhado (controles WebPart são compartilhadas por padrão)

Um usuário autorizado pode personalizar tanto Shared e propriedades com escopo do usuário no controle de todos os usuários.

No caso de um controle dinâmico (um controle que é adicionado à página programaticamente, ou a partir de um catálogo de controles), um usuário autorizado pode excluí-lo permanentemente para todos os usuários.

No caso de um controle estático (um controle que é declarado na marcação de uma página. Aspx), ele não pode ser excluído, embora um usuário autorizado pode fechar o controle de todos os usuários.

Os usuários individuais não podem personalizar propriedades com escopo como Shared. Eles podem personalizar propriedades com escopo de usuário, e seus valores para essas propriedades têm precedência sobre os valores de propriedade atribuídos quando a página estava no escopo Share. Se os dados de personalização específicas do usuário em um controle for perdido ou repor, as propriedades com escopo de usuário reverter para os valores que tinham quando a página estava no escopo Shared.

Os usuários individuais podem fechar um controle compartilhado por si mesmos, o que adiciona ao catálogo da página, mas não pode excluí-lo permanentemente.

controle por usuário

O controle não pode ser personalizado com a página no escopo Shared, porque o controle nem mesmo aparece na página. O controle só aparece quando à página está no escopo User.

Os usuários individuais podem personalizar tanto as propriedades do escopo Shared e User no controle para si, porque à instância de controle é totalmente privada.

Usuários individuais também pode excluir definitivamente o controle.

A tabela a seguir mostra os dois componentes no controle de Web Parts conjunto que são essenciais para a personalização, e que você trabalha direta ou indiretamente sempre que usar a personalização.

Controles Web Parts

Descrição

WebPartManager

Gerencia todas as Web Parts em uma página, habilita ou desabilita personalização, e gerencia o ciclo de vida dos dados de personalização. Um (e somente um) controle WebPartManager é necessário para cada página que trabalha com Web Parts.

WebPartPersonalization

Implementa a lógica necessária para realizar ações de personalização.

Contribuições da comunidade

ADICIONAR
Mostrar:
© 2016 Microsoft