Création d'un contrôle WebPart lié aux données
Mise à jour : novembre 2007
En héritant de la classe de base WebPart, vous pouvez donner des fonctions WebPart à un contrôle serveur lié aux données ordinaire. Dans les applications WebPart, les utilisateurs finaux sont capables de modifier (personnaliser) le comportement et l'interface utilisateur des contrôles serveur et leurs paramètres sont enregistrés dans le stockage à long terme pour les sessions ultérieures du navigateur. Les utilisateurs peuvent modifier radicalement l'apparence d'une page en ajoutant ou en supprimant des contrôles, en modifiant les propriétés et l'apparence des contrôles, en réorganisant la mise en page, en important ou en exportant des paramètres pour les contrôles et même en créant des connexions qui permettent aux contrôles de partager des données. Pour en savoir plus sur les applications WebPart, consultez les rubriques répertoriées dans Contrôles WebPart ASP.NET. Cette rubrique décrit les composants requis pour utiliser un contrôle WebPart lié aux données personnalisé (ou tout contrôle serveur) dans une application WebPart et décrit certains membres de la classe WebPart de base qu'il est souvent utile d'implémenter ou de substituer lors de la création d'un contrôle personnalisé. Un exemple de substitution et d'implémentation de certains de ces membres est fourni dans la rubrique Contrôle WebPart lié aux données, exemple.
Éléments requis pour utiliser un contrôle WebPart
Aucun contrôle WebPart ne peut s'exécuter de manière isolée et conserver ses fonctionnalités WebPart. Si vous exécutez un contrôle WebPart dans une application Web sans les autres éléments requis pour une application WebPart, le contrôle perd simplement ses fonctionnalités WebPart et fonctionne comme un contrôle serveur ordinaire. La liste suivante décrit les éléments requis qui doivent être en place avant de pouvoir utiliser un contrôle WebPart personnalisé avec les fonctionnalités WebPart :
Contrôle WebPartManager. Ce contrôle doit être présent sur chaque page qui offre des fonctionnalités WebPart. Pour plus d'informations, consultez Vue d'ensemble de jeu de composants WebPart.
Contrôle de zone WebPartZoneBase. Une page Web doit avoir une zone qui dérive de cette classe abstraite, telle que le contrôle WebPartZone, pour contenir des contrôles WebPart. Pour plus d'informations, consultez Vue d'ensemble de jeu de composants WebPart.
Site Web ASP.NET qui peut reconnaître les utilisateurs individuels, à l'aide de l'authentification par formulaire ou de l'authentification Windows. Pour plus d'informations sur la création d'un répertoire ou d'un site virtuel, consultez Comment : créer et configurer des répertoires virtuels dans IIS 5.0 et 6.0 ou Comment : créer et configurer des sites Web ASP.NET locaux dans IIS 6.0.
Fournisseur de personnalisations configuré et une base de données, pour stocker les paramètres utilisateur dans les contrôles. La personnalisation WebPart est activée par défaut et elle utilise le fournisseur de personnalisations SQL (SqlPersonalizationProvider) avec Microsoft SQL Server Express (SSE) pour stocker des données de personnalisation. Cette procédure pas à pas utilise SSE et le fournisseur SQL par défaut. Si SSE est installé, aucune configuration n'est requise. SSE est disponible avec Microsoft Visual Studio 2005 en tant que partie facultative de l'installation ou en tant que téléchargement libre de Microsoft.com Pour utiliser l'une des versions complètes de Microsoft SQL Server, vous devez installer et configurer une base de données des services d'application ASP.NET ainsi que le fournisseur de personnalisations SQL pour se connecter à cette base de données. Pour plus d'informations, consultez Création et configuration de la base de données des services d'application pour SQL Server. Vous pouvez également créer et configurer un fournisseur personnalisé à utiliser avec d'autres solutions de stockage ou bases de données non-SQL. Pour plus d'informations et pour obtenir un exemple de code, consultez Implémentation d'un fournisseur d'appartenances.
Membres WebPart couramment substitués ou utilisés
Bien que tout type de contrôle serveur puisse être utilisé dans les applications WebPart, il existe des avantages à la création de contrôles WebPart personnalisés (pour plus d'informations, consultez Utilisation de contrôles serveur ASP.NET dans les applications WebPart). Lorsque vous héritez de la classe de base WebPart, il n'y a aucun membre requis à implémenter. Toutefois, il existe des membres couramment utilisés que vous souhaitez utiliser ou substituer et ceux-ci sont décrits dans le tableau suivant. Pour obtenir un exemple complet d'un contrôle serveur lié aux données implémenté comme un contrôle WebPart, consultez Contrôle WebPart lié aux données, exemple. Le tableau suivant décrit certains membres fréquemment utilisés.
Membre |
Description |
|---|---|
Une utilisation commune de ce constructeur consiste à définir des valeurs par défaut pour certaines des propriétés qui déterminent l'apparence et le comportement d'un contrôle WebPart, comme les propriétés héritées de la classe Part ou les propriétés comportementales telles que les propriétés AllowEdit et AllowLayoutChange. |
|
Propriétés comportementales |
Cela inclut plusieurs propriétés "Allow" de la classe, telles que AllowClose, AllowConnect, AllowEdit, AllowMinimize, AllowLayoutChange et AllowZoneChange. Au lieu d'assigner simplement des valeurs par défaut à ces propriétés dans le constructeur, les développeurs peuvent contrôler complètement une propriété, par exemple en empêchant les utilisateurs ou les développeurs qui utilisent le contrôle de pouvoir fermer le contrôle. |
Lorsque vous héritez de la classe WebPart, vous devez fournir une interface utilisateur pour votre contrôle personnalisé. Une façon très efficace de le faire consiste à substituer la méthode CreateChildControls et d'ajouter d'autres contrôles serveur dans cette méthode pour créer l'Interface utilisateur de votre contrôle personnalisé. Vous devrez peut-être exécuter des tâches supplémentaires lorsque vous ajouterez ces contrôles, telles que la création de gestionnaires d'événements personnalisés pour ces contrôles ou leur liaison à une source de données. |
|
Méthodes de rendu |
Vous devrez peut-être substituer des méthodes de rendu courantes telles que RenderControl ou RenderContents. Dans ces méthodes, vous pouvez substituer complètement le rendu ou d'abord appeler la méthode de base puis modifier l'aspect du rendu. |
Si vous créez des objets WebPartVerb personnalisés qui apparaîtront dans le menu des verbes de votre contrôle avec les verbes standard (tels que fermer et réduire), vous devez les ajouter à la collection Verbs de votre contrôle. |
|
Si vous créez des contrôles EditorPart personnalisés, pour permettre aux utilisateurs de modifier les propriétés personnalisées de votre contrôle, vous devez les associer à votre contrôle en substituant la méthode CreateEditorParts. Pour obtenir un exemple, consultez l'interface IWebEditable. |
|
Lorsque vous créez des propriétés personnalisées dans votre contrôle WebPart, il vous arrivera souvent de vouloir que les utilisateurs puissent modifier et personnaliser ces propriétés, comme les propriétés de contrôle WebPart standard, de sorte que leurs paramètres puissent être enregistrés. Ajoutez l'attribut de métadonnées Personalizable à toute propriété que les utilisateurs doivent être en mesure de personnaliser. |
Exemple de contrôle WebPart lié aux données
Pour obtenir l'exemple de code dans son intégralité qui illustre comment créer un contrôle GridView qui crée une liaison avec la base de données Northwind et implémente le contrôle comme un contrôle WebPart, consultez Contrôle WebPart lié aux données, exemple.
Voir aussi
Tâches
Procédure pas à pas : création d'une page WebPart
Concepts
Vue d'ensemble des WebParts ASP.NET