Verwenden von ASP.NET-Serversteuerelementen in Webparts-Anwendungen

Článek
10/22/2014

Aktualisiert: November 2007

In einer Webparts-Anwendung besteht die primäre Benutzeroberfläche aus ASP.NET-Serversteuerelementen, die sich in Zonen befinden. Dies sind Bereiche auf einer Webseite, die eine gemeinsame Benutzeroberfläche aufweisen und von zusammengesetzten Steuerelementen erstellt werden, die von der WebPartZoneBase-Klasse abgeleitet werden. Die Funktionen dieser Serversteuerelemente, die die primäre Benutzeroberfläche einer Webparts-Anwendung bilden, werden in der WebPart-Basisklasse definiert. Sie sind jedoch nicht auf von dieser Klasse abgeleitete Steuerelemente beschränkt. Sie können auch beliebige Standard-ASP.NET-Serversteuerelemente, Benutzersteuerelemente oder benutzerdefinierte Serversteuerelemente verwenden. In diesem Thema werden einige Aspekte der Verwendung von Serversteuerelementen in Webparts-Anwendungen für den Fall erläutert, dass die Steuerelemente nicht von der WebPart-Klasse erben.

Erstellen von Webparts-Laufzeitsteuerelementen

Der Webparts-Steuerelementsatz stellt für die verschiedenen Arten von Serversteuerelementen, die nicht von der WebPart-Klasse erben, einen Mechanismus bereit, durch den diese in Webparts-Anwendungen verwendet werden und die gleichen Funktionen aufweisen können wie ein Steuerelement, das von der WebPart-Klasse abgeleitet wird. Dazu ist keine besondere Aktion des Entwicklers erforderlich. Es muss lediglich einer WebPartZoneBase-Zone ein Serversteuerelement hinzugefügt werden. Beim Kompilieren einer Webseite werden alle Serversteuerelemente, die sich in einer Zone befinden und nicht von der WebPart-Klasse erben, automatisch in eine Instanz der GenericWebPart-Klasse eingebunden, und sie werden zu untergeordneten Steuerelementen dieser Instanz. Da die GenericWebPart-Klasse von der WebPart-Klasse erbt, ist das Serversteuerelement jetzt aktiviert und besitzt die vollständige Funktionalität eines WebPart-Steuerelements. Durch das Hinzufügen von Serversteuerelementen, die nicht von der WebPart-Klasse erben, zu einer WebPartZoneBase-Zone aktivieren Entwickler also die Steuerelemente als WebPart-Laufzeitsteuerelemente.

Hinweis:
Ebenso wie Serversteuerelemente in Webparts-Anwendungen verwendet werden können, können auch WebPart-Steuerelemente außerhalb von Webparts-Anwendungen verwendet werden. Wenn Sie einer Seite außerhalb einer Zone ein Steuerelement hinzufügen, das von der WebPart-Klasse erbt, funktioniert es wie ein normales Serversteuerelement und verliert einfach die Webparts-Funktionen.

Hinzufügen von ASP.NET-Serversteuerelementen zu Zonen

Beim Hinzufügen von ASP.NET-Serversteuerelementen, Benutzersteuerelementen oder benutzerdefinierten Steuerelementen zu einer WebPartZoneBase-Zone sind keine besonderen Techniken oder Deklarationen auf der Seite erforderlich. Sie können einer Zone genauso hinzugefügt werden wie Steuerelemente normalerweise einer Webseite hinzugefügt werden: deklarativ (im Persistenzformat der Seite) oder programmgesteuert. Darüber hinaus können Sie das Webparts-Katalogfeature verwenden. Damit können Sie einem Katalog Serversteuerelemente hinzufügen, aus denen Benutzer zur Laufzeit Steuerelemente auswählen und der Seite hinzufügen können. Weitere Informationen finden Sie in den Themen zum DeclarativeCatalogPart-Steuerelement und zum ImportCatalogPart-Steuerelement.

Wenn Sie einer Zone ein Serversteuerelement programmgesteuert hinzufügen möchten, wird empfohlen, die AddWebPart-Methode des WebPartManager-Steuerelements zu verwenden.

Wenn Sie einer Zone Serversteuerelemente deklarativ hinzufügen, die keine WebPart-Steuerelemente sind, und Sie ein grafisch unterstütztes Entwurfstool wie Microsoft Visual Studio 2005 verwenden, werden die WebPart-Eigenschaften und Member im Eigenschaftenbereich oder in IntelliSense nicht angezeigt. Weitere Informationen finden Sie im folgenden Abschnitt, in dem erläutert wird, in welchen Fällen ein WebPart-Steuerelement oder ein anderes Serversteuerelement verwendet werden sollte.

Die Auswahl verschiedener Serversteuerelementoptionen

Da Sie beliebige Arten von Serversteuerelementen in einer Webparts-Anwendung verwenden können, fragen Sie sich möglicherweise, ob es irgendeinen Grund dafür geben könnte, ein Steuerelement zu erstellen, das von der WebPart-Klasse abgeleitet wird.

Der wichtigste Faktor bei dieser Frage ist: Welche Vorteile bietet eine Anpassung bereits vorhandener Serversteuerelemente gegenüber einer Erstellung neuer Steuerelemente, die von der WebPart-Klasse abgeleitet werden? Die folgenden Richtlinien unterstützen Sie möglicherweise bei der Entscheidungsfindung.

Verwenden von Serversteuerelementen

In vielen Fällen wird bei der Erstellung von Webparts-Steuerelementen die Option bevorzugt, ein ASP.NET-Serversteuerelement, ein Benutzersteuerelement oder ein benutzerdefiniertes Steuerelement zu verwenden, insbesondere wenn die Steuerelemente bereits vorhanden sind. Wenn Sie diese Arten von Serversteuerelementen verwenden, tritt kein Verlust der Webparts-Laufzeitfunktionalität auf, und es bieten sich viele Vorteile, z. B. können Sie vorhandenen Code wiederverwenden und Ihre Kenntnisse in der Entwicklung von Steuerelementen nutzen und sie auf Webparts-Anwendungen anwenden.

Darüber hinaus können sich die verschiedenen Serversteuerelemente genau wie echte WebPart-Steuerelemente verhalten, wenn mehrere Schnittstellen implementiert werden, die die WebPart-Klasse implementiert. Dazu gehören:

Die IWebActionable-Schnittstelle. Wenn Sie diese Schnittstelle implementieren, können Sie dem Verbenmenü des Steuerelements benutzerdefinierte Verben hinzufügen (allgemeine Aktionen, die Benutzer für ein Steuerelement in der Benutzeroberfläche ausführen können, z. B. Minimieren, Schließen oder Bearbeiten).
Die IWebEditable-Schnittstelle. Wenn Sie diese Schnittstelle implementieren, können Sie benutzerdefinierte EditorPart-Steuerelemente mit dem Serversteuerelement verknüpfen. Dies ermöglicht es Benutzern, zur Laufzeit angegebene benutzerdefinierte Eigenschaften und Verhalten des Steuerelements zu bearbeiten.
Die IWebPart-Schnittstelle. Wenn Sie diese Schnittstelle implementieren, verfügt Ihr Steuerelement über einige Eigenschaften eines echten WebPart-Steuerelements, das von der Part-Klasse geerbt wird. Dadurch erhält das Steuerelement sogar zur Entwurfszeit das Aussehen und Verhalten eines WebPart-Steuerelements.

WebPart-Ableitung

Der Hauptvorteil beim Erstellen eines Steuerelements durch Ableitung aus der WebPart-Klasse besteht darin, dass Sie die vollständige Kontrolle über das Webparts-spezifische Verhalten erlangen.

Ein Beispiel hierfür wäre, dass ein Steuerelemententwickler das Laufzeitverhalten eines Steuerelements ändern und es dann an Benutzer weitergeben möchte. Ein Entwickler könnte eine der virtuellen Eigenschaften der WebPart-Klasse (z. B. AllowClose) überschreiben und sie als schreibgeschützte Eigenschaft festlegen, die immer false zurückgibt. Dadurch wird verhindert, dass das Steuerelement jemals geschlossen wird, und Benutzer dieses Steuerelements sind auf dieses Verhalten beschränkt.

Ein zweites Beispiel, in dem das Erben von der WebPart-Klasse vorteilhaft ist, bezieht sich auf das Entwurfszeitverhalten. In einem WebPart-Steuerelement werden Seitenentwicklern zur Entwurfszeit über IntelliSense alle verfügbar gemachten WebPart-Member angezeigt (bei Verwendung eines grafisch unterstützten Entwurfstools wie Microsoft Visual Studio 2005), sodass sie mit den Eigenschaften im deklarativen Modus und im Bereich Eigenschaften arbeiten können. Im Gegensatz dazu werden in IntelliSense oder im Bereich Eigenschaften keine Member angezeigt, die für die WebPart-Klasse spezifisch sind (Sie können sie jedoch immer noch deklarieren), wenn Sie zur Entwurfszeit Serversteuerelemente in einer Zone deklarieren und diese keine WebPart-Steuerelemente sind. Dies liegt daran, dass ein gewöhnliches Serversteuerelement zur Entwurfszeit noch nicht in ein GenericWebPart-Objekt eingebunden wurde, sodass es nicht über die WebPart-Features verfügt, die es zur Laufzeit aufweist. Auch wenn Sie durch Implementieren der oben genannten Schnittstellen ein Steuerelement in Aussehen und Verhalten wie ein WebPart-Steuerelement gestalten können, ist es oft leichter, einfach ein WebPart-Steuerelement zu erstellen. Steuerelemententwickler und Händler, die Steuerelementpakete erstellen, können vom Ableiten von der WebPart-Klasse profitieren, damit sie umfangreichere Features zur Entwurfszeit bereitstellen können.

Schlussfolgerungen

Wenn es nicht erforderlich ist, die Standardeigenschaften des Steuerelements zu überschreiben, ist es möglicherweise einfacher, bereits vorhandene Serversteuerelemente zu verwenden und diese in das WebPart-Steuerelement zu integrieren.

Im Folgenden sind die Eigenschaften aufgeführt, die überschrieben werden können, wenn Sie ein benutzerdefiniertes WebPart-Steuerelement erstellen:

Benutzersteuerelemente als Webparts-Steuerelemente

Benutzersteuerelemente stellen eine leistungsfähige Alternative für ASP.NET-Entwickler dar, da diese dadurch die Möglichkeit erhalten, auf schnellem Weg und mithilfe der gleichen deklarativen Syntax, die auch für Webseiten verwendet wird, eine komplexe Benutzeroberfläche für ein Steuerelement zu erstellen. Darüber hinaus bieten Benutzersteuerelemente eine einfache Methode zum Partitionieren und Wiederverwenden von Code auf mehreren Seiten. Benutzersteuerelemente sind als ASP.NET-Serversteuerelemente auch eine ausgezeichnete Option für die Verwendung in Webparts-Anwendungen. Benutzersteuerelemente können einer WebPartZoneBase-Zone direkt hinzugefügt werden, und sie funktionieren wie oben beschrieben als WebPart-Laufzeitsteuerelemente. Sie können auch mit dem Webparts-Katalogfeature verwendet werden, entweder als Steuerelemente, die importiert werden können, oder um einen Satz anderer Serversteuerelemente zu gruppieren, die von Benutzern ausgewählt und einer Seite hinzugefügt werden können (weitere Informationen finden Sie unter der Beschreibung der WebPartsListUserControlPath-Eigenschaft).

Wichtiger Hinweis:
Sie sollten beachten, dass die ASP.NET-Ausgabecachefunktion für Benutzersteuerelemente, die als WebPart-Laufzeitsteuerelemente verwendet werden, deaktiviert ist. Der Webparts-Steuerelementsatz erfordert, dass für jede Anforderung an eine Seite ein Steuerelement in der Steuerelementstruktur vorhanden ist. Dies ist für das ordnungsgemäße Funktionieren bestimmter Webparts-Features (wie Personalisierung) erforderlich. Weitere Informationen finden Sie unter Übersicht über die Webparts-Personalisierung. Bei Anforderungen, für die ein Benutzersteuerelement zwischengespeichert wird (weitere Informationen finden Sie unter der Beschreibung der @ OutputCache-Direktive), wird es der Steuerelementstruktur nicht hinzugefügt. Aus diesem Grund ist die Ausgabecachefunktion nicht mit Webparts-Features kompatibel, und sie funktioniert nicht mit Benutzersteuerelementen, die als WebPart-Steuerelemente in einer Webparts-Anwendung funktionieren.

Sie sollten beachten, dass die ASP.NET-Ausgabecachefunktion für Benutzersteuerelemente, die als WebPart-Laufzeitsteuerelemente verwendet werden, deaktiviert ist. Der Webparts-Steuerelementsatz erfordert, dass für jede Anforderung an eine Seite ein Steuerelement in der Steuerelementstruktur vorhanden ist. Dies ist für das ordnungsgemäße Funktionieren bestimmter Webparts-Features (wie Personalisierung) erforderlich. Weitere Informationen finden Sie unter Übersicht über die Webparts-Personalisierung. Bei Anforderungen, für die ein Benutzersteuerelement zwischengespeichert wird (weitere Informationen finden Sie unter der Beschreibung der @ OutputCache-Direktive), wird es der Steuerelementstruktur nicht hinzugefügt. Aus diesem Grund ist die Ausgabecachefunktion nicht mit Webparts-Features kompatibel, und sie funktioniert nicht mit Benutzersteuerelementen, die als WebPart-Steuerelemente in einer Webparts-Anwendung funktionieren.