Vue d'ensemble de la personnalisation des WebParts

Article
10/22/2014

Mise à jour : novembre 2007

Dans certaines applications Web, vous pouvez souhaiter autoriser les utilisateurs à modifier, ou personnaliser, l'interface utilisateur et le comportement de l'application. Le jeu de composants WebPart ASP.NET offre cette possibilité dans l'une de ses fonctionnalités principales, la personnalisation. La personnalisation permet aux propriétés ou à l'état des contrôles WebPart d'être enregistrés dans le stockage à long terme et de ne pas être liés à une session de navigateur particulière.

Fonctionnement de la personnalisation

La personnalisation vous permet de créer des propriétés pour les contrôles WebPart qui ont plusieurs caractéristiques uniques. Les propriétés personnalisables sont :

Lié à l'identité d'un utilisateur spécifique et à une page Web. Les paramètres de chaque utilisateur pour les contrôles personnalisables de chaque page peuvent être enregistrés dans les données de personnalisation. Ces données permettent aux utilisateurs de modifier l'interface utilisateur d'une page Web et d'enregistrer leurs préférences.
À durée de vie longue Les paramètres personnalisés ne sont pas liés à une seule session de navigateur. Étant donné qu'ils sont stockés dans le stockage à long terme, l'application peut récupérer les paramètres d'un utilisateur chaque fois que l'utilisateur visite une page spécifique.

La personnalisation utilise une base de données des services d'application ASP.NET pour stocker des données de personnalisation. Par défaut, ASP.NET crée automatiquement cette base de données dans un sous-dossier nommé « app_data » lorsqu'une application ASP.NET utilise en premier la personnalisation ou un des autres services d'application tels que les rôles, l'appartenance ou les profils. Également par défaut, ASP.NET crée la base de données en tant que fichier de la base de données SQL Server Express unique qui contient le schéma de la base de données pour tous les services d'application. À l'aide du fichier Web.config, vous pouvez configurer votre application afin qu'un fichier de base de données distinct soit créé pour la personnalisation. En outre, vous pouvez spécifier une base de données SQL Server pour stocker les données des services d'application dans le fichier Web.config, au lieu d'utiliser le fichier de la base de données SQL Server Express par défaut.
Rendues persistantes à travers une couche de fournisseur. Le mécanisme de stockage et de récupération des données de personnalisation se compose d'un composant fournisseur et d'un magasin de données. ASP.NET inclut un fournisseur et une base de données Microsoft SQL par défaut. Vous pouvez également créer un fournisseur personnalisé et le configurer pour utiliser n'importe quel magasin de données.

Déclaratif sur tout contrôle WebPart. Lorsque vous développez un contrôle personnalisé, vous pouvez ajouter l'attribut Personalizable dans le code pour activer une propriété particulière sur tout contrôle WebPart pour la personnalisation. En plus des contrôles personnalisés dérivés de la classe WebPart, cela s'applique également aux contrôles serveur, aux contrôles serveur personnalisés ou aux contrôles utilisateur ASP.NET, car ils peuvent être utilisés en tant que contrôles WebPart.

Remarque :
Il est important de savoir que les propriétés ordinaires sont gérées différemment en ce sens qu'elles ne peuvent être rendues persistantes comme des propriétés personnalisables. Si vous ajoutez par programme un contrôle WebPart ou un autre contrôle serveur à une zone WebPartZoneBase et si vous essayez de définir ses propriétés non personnalisables par programme (par exemple, si vous définissez la propriété Text d'un contrôle Label), la valeur par défaut des propriétés sont rétablies après avoir ajouté les contrôles, car il n'existe aucune façon pour ces valeurs de propriété d'être rendues persistantes dans le stockage de la personnalisation à long terme. Pour rendre les propriétés persistantes dans le stockage à long terme, celles-ci doivent être marquées avec l'attribut Personalizable dans le code source. Si vous souhaitez rendre les propriétés persistantes uniquement d'une demande à une autre dans la même session de navigateur (mais pas dans le stockage à long terme), vous pouvez également utiliser l'état d'affichage.

Il est important de savoir que les propriétés ordinaires sont gérées différemment en ce sens qu'elles ne peuvent être rendues persistantes comme des propriétés personnalisables. Si vous ajoutez par programme un contrôle WebPart ou un autre contrôle serveur à une zone WebPartZoneBase et si vous essayez de définir ses propriétés non personnalisables par programme (par exemple, si vous définissez la propriété Text d'un contrôle Label), la valeur par défaut des propriétés sont rétablies après avoir ajouté les contrôles, car il n'existe aucune façon pour ces valeurs de propriété d'être rendues persistantes dans le stockage de la personnalisation à long terme. Pour rendre les propriétés persistantes dans le stockage à long terme, celles-ci doivent être marquées avec l'attribut Personalizable dans le code source. Si vous souhaitez rendre les propriétés persistantes uniquement d'une demande à une autre dans la même session de navigateur (mais pas dans le stockage à long terme), vous pouvez également utiliser l'état d'affichage.

Personnalisation et autres fonctionnalités ASP.NET

La personnalisation contraste de plusieurs façons avec les autres techniques ASP.NET pour rendre les données d'état d'une application Web persistantes :

La personnalisation est une fonctionnalité des WebParts. Vous ne pouvez pas utiliser la personnalisation seule. Pour utiliser la personnalisation, vous devez utiliser des contrôles dans un WebPartZone afin qu'ils aient les fonctionnalités WebPart.

Remarque :

Un contrôle serveur, un contrôle personnalisé ou un contrôle utilisateur ASP.NET peut être utilisé comme un contrôle WebPart pour tirer parti de la personnalisation.
La personnalisation est différente de l'état d'affichage. L'état d'affichage et la personnalisation rendent tous deux persistantes les données d'état du contrôle, mais les données de l'état d'affichage persistent uniquement pendant la session de navigateur actuelle, alors que les données de personnalisation sont à durée de vie longue.
La personnalisation diffère des profils. La personnalisation stocke uniquement les données d'état spécifiques à l'utilisateur pour les contrôles d'une page Web particulière. Les informations relatives à l'utilisateur comme une personne, et qui sont destinées à être utilisées sur plusieurs pages dans une application Web (telles que les informations relatives au compte dans une application de panier d'achat), doivent être conservées dans un profil. Pour plus d'informations, consultez Vue d'ensemble des propriétés du profil ASP.NET.

Remarque :
Un contrôle serveur, un contrôle personnalisé ou un contrôle utilisateur ASP.NET peut être utilisé comme un contrôle WebPart pour tirer parti de la personnalisation.

Concepts clés de la personnalisation

Lorsque vous utilisez la personnalisation avec les contrôles WebPart, vous devez comprendre les différents concepts qui affectent le fonctionnement de la personnalisation.

Le premier concept est la portée de personnalisation de la page. La portée de personnalisation de la page est la plage d'utilisateurs à laquelle peuvent s'appliquer les modifications de personnalisation sur une page. À un moment donné, une page WebPart peut être dans l'une des deux portées de personnalisation de la page possibles, partagée ou utilisateur. Dans la portée partagée, toutes les modifications de personnalisation sur la page s'appliquent à tous les utilisateurs ; dans la portée utilisateur, les modifications de personnalisation sur la page s'appliquent uniquement à l'utilisateur actuel.

Un deuxième concept connexe est la visibilité de contrôle. La visibilité de contrôle détermine si un contrôle donné est visible à un utilisateur ou à tous les utilisateurs. Chaque contrôle WebPart sur une page est un contrôle partagé, visible à tous les utilisateurs de cette page ou un contrôle par utilisateur, visible à un utilisateur uniquement. La visibilité est déterminée par l'ajout d'un contrôle à une page. Si un contrôle est ajouté en le déclarant dans le balisage d'une page Web (un contrôle statique), c'est toujours un contrôle partagé. Si un contrôle est ajouté par le code de l'application ou par un utilisateur qui le sélectionne dans un catalogue de contrôles (un contrôle dynamique), la visibilité est déterminée par la portée de personnalisation actuelle de la page. Si la page est dans la portée partagée, un contrôle ajouté dynamiquement est partagé et si la page est dans la portée utilisateur, le contrôle est un contrôle par utilisateur.

Un troisième concept important est la portée de propriété. Lorsque vous créez une propriété personnalisable sur un contrôle à l'aide de l'attribut Personalizable dans le code source, vous pouvez affecter Shared ou User (User est la portée par défaut) à la portée de personnalisation pour la propriété. Cela fournit un contrôle détaillé sur lequel les propriétés d'un contrôle peuvent être personnalisées par tous les utilisateurs et qui peut être personnalisé uniquement par les utilisateurs autorisés lorsque la portée de page est Shared.

Ensemble, ces concepts de portée de personnalisation de la page, de visibilité de contrôle et de portée de personnalisation de la propriété créent la plage d'options pour l'affichage et la personnalisation des contrôles WebPart par les utilisateurs. Le tableau suivant résume comment les contrôles WebPart se comportent lorsque les utilisateurs les personnalisent dans les différentes portées.

Visibilité de contrôle	Page dans la portée partagée	Page dans la portée utilisateur
contrôle partagé (les contrôles WebPart sont partagés par défaut)	Un utilisateur autorisé peut personnaliser les propriétés de portée partagée et utilisateur du contrôle pour tous les utilisateurs. Dans le cas d'un contrôle dynamique (un contrôle qui est ajouté par programme à la page ou provenant d'un catalogue de contrôles), un utilisateur autorisé peut le supprimer définitivement pour tous les utilisateurs. Dans le cas d'un contrôle statique (un contrôle qui est déclaré dans le balisage d'une page .aspx), il ne peut pas être supprimé, bien qu'un utilisateur autorisé puisse fermer le contrôle pour tous les utilisateurs.	Les utilisateurs ne peuvent pas personnaliser les propriétés de portée partagée. Ils peuvent personnaliser des propriétés de portée utilisateur et leurs valeurs pour ces propriétés sont prioritaires sur les valeurs de propriété assignées lorsque la page était dans la portée partagée. Si les données de personnalisation spécifiques à l'utilisateur d'un contrôle sont perdues ou sont réinitialisées, les propriétés de portée utilisateur rétablissent les valeurs qu'elles avaient lorsque la page était dans la portée partagée. Les utilisateurs peuvent fermer un contrôle partagé pour eux-mêmes, ce qui l'ajoute au catalogue de pages, mais ils ne peuvent pas le supprimer définitivement.
contrôle par utilisateur	Le contrôle ne peut pas être personnalisé avec la page dans la portée partagée, parce que le contrôle n'apparaît même pas sur la page. Le contrôle apparaît seulement lorsque la page est dans la portée utilisateur.	Les utilisateurs peuvent personnaliser les propriétés personnalisables de portée partagée et utilisateur du contrôle pour eux-mêmes, étant donné que l'instance de contrôle est totalement privée. Les utilisateurs peuvent également supprimer définitivement le contrôle.

contrôle partagé (les contrôles WebPart sont partagés par défaut)

Un utilisateur autorisé peut personnaliser les propriétés de portée partagée et utilisateur du contrôle pour tous les utilisateurs.

Dans le cas d'un contrôle dynamique (un contrôle qui est ajouté par programme à la page ou provenant d'un catalogue de contrôles), un utilisateur autorisé peut le supprimer définitivement pour tous les utilisateurs.

Dans le cas d'un contrôle statique (un contrôle qui est déclaré dans le balisage d'une page .aspx), il ne peut pas être supprimé, bien qu'un utilisateur autorisé puisse fermer le contrôle pour tous les utilisateurs.

Les utilisateurs ne peuvent pas personnaliser les propriétés de portée partagée. Ils peuvent personnaliser des propriétés de portée utilisateur et leurs valeurs pour ces propriétés sont prioritaires sur les valeurs de propriété assignées lorsque la page était dans la portée partagée. Si les données de personnalisation spécifiques à l'utilisateur d'un contrôle sont perdues ou sont réinitialisées, les propriétés de portée utilisateur rétablissent les valeurs qu'elles avaient lorsque la page était dans la portée partagée.

Les utilisateurs peuvent fermer un contrôle partagé pour eux-mêmes, ce qui l'ajoute au catalogue de pages, mais ils ne peuvent pas le supprimer définitivement.

contrôle par utilisateur

Le contrôle ne peut pas être personnalisé avec la page dans la portée partagée, parce que le contrôle n'apparaît même pas sur la page. Le contrôle apparaît seulement lorsque la page est dans la portée utilisateur.

Les utilisateurs peuvent personnaliser les propriétés personnalisables de portée partagée et utilisateur du contrôle pour eux-mêmes, étant donné que l'instance de contrôle est totalement privée.

Les utilisateurs peuvent également supprimer définitivement le contrôle.

Composants essentiels de la personnalisation

Le tableau suivant présente les deux composants du jeu de composants WebPart qui sont essentiels à la personnalisation et que vous utilisez directement ou indirectement lorsque vous utilisez la personnalisation.

Contrôle WebPart	Description
WebPartManager	Gère tous les WebParts d'une page, active ou désactive la personnalisation et gère le cycle de vie des données de personnalisation. Un (et un seul) contrôle WebPartManager est requis pour chaque page WebPart.
WebPartPersonalization	Implémente la logique nécessaire pour effectuer des actions de personnalisation.