Utilisation de contrôles serveur ASP.NET dans les applications WebPart

Article
10/22/2014

Mise à jour : novembre 2007

Dans une application WebPart, l'interface utilisateur principale se compose de contrôles serveur ASP.NET qui résident dans des zones, régions d'une page Web qui possèdent une interface utilisateur commune et sont créées par un type de contrôle composite dérivé de la classe WebPartZoneBase. Les fonctionnalités de ces contrôles serveur qui forment l'interface utilisateur principale d'une application WebPart sont définies dans la classe WebPart de base, mais vous n'êtes pas limités à l'utilisation des contrôles qui dérivent de cette classe. Vous pouvez également utiliser un contrôle serveur ASP.NET standard, un contrôle utilisateur ou un contrôle serveur personnalisé. Cette rubrique décrit certains problèmes liés à l'utilisation de contrôles serveur dans les applications WebPart lorsque les contrôles n'héritent pas de la classe WebPart.

Création de contrôles WebPart au moment de l'exécution

Pour les différents types de contrôles serveur qui n'héritent pas de la classe WebPart, le jeu de contrôles WebPart fournit un mécanisme qui leur permet de participer aux applications WebPart et d'avoir les mêmes fonctionnalités qu'un contrôle dérivé de la classe WebPart. Cela ne requiert pas d'intervention spéciale des développeurs ; il suffit d'ajouter un contrôle serveur à une zone WebPartZoneBase. Lorsqu'une page Web est compilée, tout contrôle serveur qui réside dans une zone et qui n'hérite pas de la classe WebPart est automatiquement encapsulé avec une instance de la classe GenericWebPart et devient un contrôle enfant de cette instance. Étant donné que la classe GenericWebPart hérite de la classe WebPart, le contrôle serveur est maintenant activé avec les fonctionnalités complètes d'un contrôle WebPart. Les développeurs permettent essentiellement aux contrôles de devenir des contrôles WebPart au moment de l'exécution en ajoutant des contrôles serveur qui n'héritent pas de la classe WebPart à une zone WebPartZoneBase.

Remarque :
De même que vous pouvez utiliser des contrôles serveur dans les applications WebPart, vous pouvez également utiliser des contrôles WebPart en dehors d'applications WebPart. Si vous ajoutez un contrôle qui hérite de la classe WebPart à une page située en dehors d'une zone, il fonctionne comme un contrôle serveur normal et perd simplement ses fonctions WebPart.

Ajout de contrôles serveur ASP.NET à des zones

Lorsque vous ajoutez des contrôles serveur ASP.NET, des contrôles utilisateur ou des contrôles personnalisés à une zone WebPartZoneBase, aucune technique spéciale ou déclaration sur la page n'est requise. Vous pouvez les ajouter à une zone comme si vous ajoutiez normalement des contrôles à une page Web : de manière déclarative (dans le format de la persistance de page) ou par programme. De plus, vous pouvez utiliser les fonctionnalités de catalogue WebPart qui vous permettent d'ajouter des contrôles serveur à un catalogue dans lequel les utilisateurs peuvent sélectionner et ajouter des contrôles à la page au moment de l'exécution. Pour plus d'informations, consultez les contrôles DeclarativeCatalogPart et ImportCatalogPart.

Si vous ajoutez par programme un contrôle serveur à une zone, l'approche recommandée consiste à l'ajouter à l'aide de la méthode AddWebPart du contrôle WebPartManager.

Lorsque vous ajoutez des contrôles serveur qui ne sont pas de manière déclarative des contrôles WebPart d'une zone, si vous utilisez un outil de conception visuel tel que Microsoft Visual Studio 2005, aucune propriété WebPart ni membre n'apparaîtra dans le volet de propriétés ou dans IntelliSense. Pour plus d'informations, consultez la section suivante qui explique quand utiliser des contrôles WebPart et quand utiliser d'autres contrôles serveur.

Quand utiliser les différentes options du contrôle serveur

Dans la mesure où vous pouvez utiliser tout type de contrôle serveur dans une application WebPart, vous pouvez vous demander s'il existe une raison de créer un contrôle qui dérive de la classe WebPart.

Les facteurs clés que vous devez considérer sont les avantages liés à l'adaptation de contrôles serveur préexistants par rapport à la création de contrôles dérivés de la classe WebPart. Les indications suivantes peuvent vous aider dans votre décision.

Utilisation de contrôles serveur

Dans la plupart des cas, l'option préférée pour créer des contrôles WebPart consiste à utiliser un contrôle serveur ASP.NET, un contrôle utilisateur ou un contrôle personnalisé, en particulier si les contrôles existent déjà. Vous ne perdez aucune fonctionnalité WebPart au moment de l'exécution lorsque vous utilisez ces types de contrôles serveur et vous bénéficiez de nombreux avantages, tels que la possibilité de réutiliser le code existant et d'approfondir vos connaissances dans le développement de contrôle pour les appliquer aux applications WebPart.

Vous pouvez également faire en sorte que les différents contrôles serveur se comportent de manière identique par rapport aux véritables contrôles WebPart en implémentant plusieurs interfaces que la classe WebPart implémente. Ces interfaces sont les suivantes :

Interface IWebActionable. Si vous implémentez cette interface, vous serez en mesure d'ajouter des verbes personnalisés (actions courantes que les utilisateurs peuvent exécuter sur un contrôle dans l'interface utilisateur, telles que réduire, fermer ou modifier) au menu des verbes de votre contrôle.
Interface IWebEditable. Si vous implémentez cette interface, vous pouvez associer des contrôles EditorPart personnalisés à votre contrôle serveur, permettant aux utilisateurs de modifier les propriétés personnalisées et le comportement spécifiés sur le contrôle au moment de l'exécution.
Interface IWebPart. Si vous implémentez cette interface, votre contrôle aura plusieurs propriétés d'un véritable contrôle WebPart hérité de la classe Part, ce qui lui donne la même apparence qu'un contrôle WebPart, même au moment du design.

Dérivation de WebPart

L'avantage principal de la création d'un contrôle en dérivant de la classe WebPart est que vous obtenez le contrôle total sur son comportement spécifique aux WebParts.

Par exemple, cela se produit lorsqu'un développeur de contrôle souhaite modifier le comportement au moment de l'exécution d'un contrôle, puis le redistribuer aux utilisateurs. Un développeur pourrait substituer l'une des propriétés virtuelles de la classe WebPart, telle que AllowClose, et la faire passer en lecture seule qui retourne toujours false. Cela empêche la fermeture du contrôle, et les utilisateurs du contrôle sont limités à ce comportement.

Par exemple, vous pouvez également en tirer parti en héritant de la classe WebPart associée au comportement au moment du design. Sur un contrôle WebPart, tous les membres WebPart exposés sont visibles par les développeurs de pages au moment du design via IntelliSense (s'ils utilisent un outil de conception visuel tel que Microsoft Visual Studio 2005), afin qu'ils puissent utiliser les propriétés en mode déclaratif et dans le volet Propriétés. Par opposition, si vous déclarez des contrôles serveur dans une zone au moment du design et qu'ils ne sont pas des contrôles WebPart, vous ne pouvez pas afficher les membres spécifiques à la classe WebPart (bien que vous puissiez toujours les déclarer) dans IntelliSense ou dans le volet Propriétés. Cela est dû au fait que, au moment du design, un contrôle serveur ordinaire n'a pas encore été encapsulé avec un objet GenericWebPart, donc n'a pas les fonctionnalités WebPart qu'il aura au moment de l'exécution. Même si vous pouvez permettre aux contrôles serveur d'avoir l'apparence et le comportement des contrôles WebPart en implémentant les interfaces répertoriées ci-dessus, il est souvent plus simple de créer un contrôle WebPart. Les développeurs et fournisseurs de contrôles qui créent des packages de contrôles peuvent bénéficier de la dérivation de la classe WebPart afin de pouvoir fournir des fonctionnalités au moment du design plus riches à leurs contrôles.

Conclusions

En conclusion, si vous n'avez pas besoin de substituer les propriétés standard des contrôles, il peut être plus simple d'utiliser les contrôles serveur préexistants et de les intégrer au contrôle WebPart.

Si vous décidez de créer un contrôle WebPart personnalisé, les éléments suivants sont les propriétés que vous pouvez substituer potentiellement :

Contrôles utilisateur et contrôles WebPart

Les contrôles utilisateur sont une option puissante pour les développeurs ASP.NET, car ils leur permettent de générer rapidement une interface utilisateur complexe pour un contrôle à l'aide de la même syntaxe déclarative qui est utilisée dans les pages Web. Ils représentent également un moyen pratique de partitionner et réutiliser le code sur plusieurs pages. Comme les contrôles serveur ASP.NET, les contrôles utilisateur sont également une excellente option à utiliser dans les applications WebPart. Les contrôles utilisateur peuvent être ajoutés directement dans une zone WebPartZoneBase et ils fonctionneront comme des contrôles WebPart au moment de l'exécution, comme décrit ci-dessus. Ils peuvent également être utilisés avec la fonctionnalité de catalogue WebPart ou comme des contrôles qui peuvent être importés ou pour empaqueter un jeu d'autres contrôles serveur que les utilisateurs peuvent sélectionner et ajouter à une page (pour plus d'informations, consultez la propriété WebPartsListUserControlPath).

Remarque importante :
Vous devez savoir que la mise en cache de sortie ASP.NET est désactivée sur les contrôles utilisateur qui sont utilisés comme contrôles WebPart au moment de l'exécution. Le jeu de contrôles WebPart suppose qu'un contrôle se trouve dans l'arborescence du contrôle pour chaque demande à une page. Cela est nécessaire pour que certaines fonctionnalités WebPart, telles que la personnalisation (pour plus d'informations, consultez Vue d'ensemble de la personnalisation des WebParts), fonctionnent. Sur les demandes où un contrôle utilisateur est mis en cache (pour plus d'informations, consultez la directive @ OutputCache), il n'est pas ajouté à l'arborescence du contrôle. Pour cette raison, la mise en cache de sortie est incompatible avec les fonctionnalités WebPart et n'utilise pas les contrôles utilisateur qui fonctionnent comme contrôles WebPart dans une application WebPart.

Vous devez savoir que la mise en cache de sortie ASP.NET est désactivée sur les contrôles utilisateur qui sont utilisés comme contrôles WebPart au moment de l'exécution. Le jeu de contrôles WebPart suppose qu'un contrôle se trouve dans l'arborescence du contrôle pour chaque demande à une page. Cela est nécessaire pour que certaines fonctionnalités WebPart, telles que la personnalisation (pour plus d'informations, consultez Vue d'ensemble de la personnalisation des WebParts), fonctionnent. Sur les demandes où un contrôle utilisateur est mis en cache (pour plus d'informations, consultez la directive @ OutputCache), il n'est pas ajouté à l'arborescence du contrôle. Pour cette raison, la mise en cache de sortie est incompatible avec les fonctionnalités WebPart et n'utilise pas les contrôles utilisateur qui fonctionnent comme contrôles WebPart dans une application WebPart.