Übersicht über die Webparts-Personalisierung

Artikel
10/22/2014

Aktualisiert: November 2007

In einigen Webanwendungen möchten Sie es den Benutzern ggf. ermöglichen, die Benutzeroberfläche und das Verhalten der Anwendung zu ändern oder zu personalisieren. Die Gruppe von ASP.NET-Webparts-Steuerelementen stellt in einem ihrer Kernfeatures, der Personalisierung, diese Fähigkeit bereit. Mithilfe der Personalisierung können die Eigenschaften oder der Zustand von Webparts-Steuerelementen im Langzeitspeicher gespeichert werden und sind nicht an eine bestimmte Browsersitzung gebunden.

Prinzip der Personalisierung

Die Personalisierung ermöglicht es Ihnen, Eigenschaften für Webparts-Steuerelemente zu erstellen, die mehrere eindeutige Merkmale aufweisen. Personalisierbare Eigenschaften weisen folgende Merkmale auf:

Sie sind an die Identität eines bestimmten Benutzers und einer Webseite gebunden. Die Einstellungen jedes Benutzers für die personalisierbaren Steuerelemente auf jeder Seite können in Personalisierungsdaten gespeichert werden. Diese Daten ermöglichen es Benutzern, die Benutzeroberfläche auf einer Webseite zu ändern und ihre individuellen Einstellungen zu speichern.
Sie sind langlebig. Personalisierte Einstellungen sind nicht an eine einzelne Browsersitzung gebunden. Da die Benutzereinstellungen im Langzeitspeicher gespeichert werden, können sie jedes Mal, wenn der Benutzer eine bestimmte Seite besucht, von der Anwendung abgerufen werden.

Bei der Personalisierung werden Personalisierungsdaten in einer Datenbank der ASP.NET-Anwendungsdienste gespeichert. Standardmäßig erstellt ASP.NET diese Datenbank automatisch in einem Unterordner mit dem Namen "app_data", wenn eine ASP.NET-Anwendung zum ersten Mal die Personalisierung oder einen anderen Anwendungsdienst, z. B. Rollen, Mitgliedschaft oder Profile, verwendet. Ebenso erstellt ASP.NET die Datenbank standardmäßig als einzelne SQL Server Express-Datenbankdatei, die das Datenbankschema für alle Anwendungsdienste enthält. Mithilfe der Datei Web.config können Sie die Anwendung so konfigurieren, dass eine eigene Datenbankdatei für die Personalisierung erstellt wird. Weiterhin können Sie in der Datei Web.config statt der standardmäßigen SQL Server Express-Datenbankdatei eine SQL Server-Datenbank angeben, in der die Daten der Anwendungsdienste gespeichert werden.
Sie werden auf Anbieterebene beibehalten. Der Mechanismus für das Speichern und Abrufen von Personalisierungsdaten besteht aus einer Anbieterkomponente und einem Datenspeicher. ASP.NET enthält einen Standard-Microsoft SQL-Anbieter und -Datenbank. Sie können auch einen benutzerdefinierten Anbieter erstellen und ihn so konfigurieren, dass beliebige Datenspeicher verwendet werden.

Sie sind für beliebige Webparts-Steuerelemente deklarativ. Bei der Entwicklung eines benutzerdefinierten Steuerelements können Sie das Personalizable-Attribut im Code hinzufügen, damit für die Personalisierung eine bestimmte Eigenschaft für jedes Webparts-Steuerelement aktiviert wird. Dies gilt nicht nur für benutzerdefinierte Steuerelemente, die von der WebPart-Klasse abgeleitet wurden, sondern auch für ASP.NET-Serversteuerelemente, benutzerdefinierte Serversteuerelemente und Benutzersteuerelemente, da sie als Webparts-Steuerelemente verwendet werden können.

Hinweis:
Es ist wichtig zu verstehen, dass normale Eigenschaften anders behandelt werden, weil sie im Unterschied zu personalisierbaren Eigenschaften nicht beibehalten werden können. Wenn Sie einer WebPartZoneBase-Zone ein WebPart-Steuerelement oder ein anderes Serversteuerelement programmgesteuert hinzufügen und versuchen, die nicht personalisierbaren Eigenschaften programmgesteuert festzulegen (wenn Sie beispielsweise die Text-Eigenschaft für ein Label-Steuerelement festlegen), werden nach dem Hinzufügen der Steuerelemente deren Eigenschaften auf ihre Standardwerte zurückgesetzt, weil es keine Möglichkeit gibt, die Werte dieser Eigenschaften im Langzeit-Personalisierungsspeicher beizubehalten. Damit die Eigenschaften im Langzeitspeicher erhalten bleiben, müssen sie mit dem Personalizable-Attribut im Quellcode gekennzeichnet werden. Wenn Sie die Eigenschaften lediglich über mehrere Anforderungen hinweg in derselben Browsersitzung (und nicht im Langzeitspeicher) beibehalten möchten, können Sie alternativ den Ansichtszustand verwenden.

Es ist wichtig zu verstehen, dass normale Eigenschaften anders behandelt werden, weil sie im Unterschied zu personalisierbaren Eigenschaften nicht beibehalten werden können. Wenn Sie einer WebPartZoneBase-Zone ein WebPart-Steuerelement oder ein anderes Serversteuerelement programmgesteuert hinzufügen und versuchen, die nicht personalisierbaren Eigenschaften programmgesteuert festzulegen (wenn Sie beispielsweise die Text-Eigenschaft für ein Label-Steuerelement festlegen), werden nach dem Hinzufügen der Steuerelemente deren Eigenschaften auf ihre Standardwerte zurückgesetzt, weil es keine Möglichkeit gibt, die Werte dieser Eigenschaften im Langzeit-Personalisierungsspeicher beizubehalten. Damit die Eigenschaften im Langzeitspeicher erhalten bleiben, müssen sie mit dem Personalizable-Attribut im Quellcode gekennzeichnet werden. Wenn Sie die Eigenschaften lediglich über mehrere Anforderungen hinweg in derselben Browsersitzung (und nicht im Langzeitspeicher) beibehalten möchten, können Sie alternativ den Ansichtszustand verwenden.

Personalisierung und andere ASP.NET-Features

Die Personalisierung hebt sich in verschiedener Hinsicht von den anderen ASP.NET-Verfahren ab, weil die Zustandsdaten von Webanwendungen beibehalten werden:

Personalisierung ist ein Feature von Webparts. Sie können die Personalisierung nicht als solches verwenden. Für die Personalisierung müssen Steuerelemente innerhalb einer WebPartZone so verwendet werden, dass sie Webparts-Funktionalität aufweisen.

Hinweis:
Jedes ASP.NET-Serversteuerelement, jedes benutzerdefinierte Steuerelement und jedes Benutzersteuerelement kann als Webparts-Steuerelement zugunsten der Personalisierung verwendet werden.

Personalisierung unterscheidet sich vom Ansichtszustand. Ansichtszustand und Personalisierung behalten beide die Zustandsdaten von Steuerelementen bei. Die Ansichtszustandsdaten bleiben nur während der aktuellen Browsersitzung erhalten, Personalisierungsdaten hingegen sind langlebig.
Personalisierung unterscheidet sich von Profilen. Bei der Personalisierung werden nur die benutzerspezifischen Zustandsdaten für Steuerelemente auf einer besonderen Webseite gespeichert. Es empfiehlt sich, Informationen, die sich auf den Benutzer als Person beziehen und die über mehrere Seiten hinweg in einer Webanwendung (z. B. Kontoinformationen in einer Einkaufswagenanwendung) verwendet werden, in einem Profil zu speichern. Weitere Informationen finden Sie unter Übersicht über ASP.NET-Profileigenschaften.

Grundbegriffe der Personalisierung

Bei der Verwendung von Personalisierung für Webparts-Steuerelemente müssen Sie sich mit mehreren Konzepten vertraut machen, die die Funktionsweise der Personalisierung beeinflussen.

Das erste Konzept ist der Seitenpersonalisierungsbereich. Bei dem Seitenpersonalisierungsbereich handelt es sich um den Bereich von Benutzern, für den Personalisierungsänderungen auf einer Seite gelten können. Zu jedem Zeitpunkt kann sich eine Webparts-Seite in einem von zwei möglichen Seitenpersonalisierungsbereichen befinden: im freigegebenen Bereich oder im Benutzerbereich. Im freigegebenen Bereich gelten alle Personalisierungsänderungen auf der Seite für alle Benutzer. Im Benutzerbereich gelten die Personalisierungsänderungen auf der Seite nur für den aktuellen Benutzer.

Ein zweites, damit verwandtes Konzept ist die Steuerelementsichtbarkeit. Die Steuerelementsichtbarkeit bestimmt, ob ein gegebenes Steuerelement für einen einzelnen Benutzer oder für alle Benutzer sichtbar ist. Jedes WebPart-Steuerelement auf einer Seite ist entweder ein freigegebenes Steuerelement, das für alle Benutzer dieser Seite sichtbar ist, oder ein Benutzersteuerelement, das nur für einen einzelnen Benutzer sichtbar ist. Die Sichtbarkeit ist davon abhängig, wie einer Seite ein Steuerelement hinzugefügt wird. Wenn ein Steuerelement durch Deklarieren im Markup einer Webseite festgelegt wird (statisches Steuerelement), handelt es sich immer um ein freigegebenes Steuerelement. Wenn ein Steuerelement durch den Anwendungscode oder durch einen Benutzer hinzugefügt wird, der es aus einem Katalog von Steuerelementen auswählt (dynamisches Steuerelement), wird die Sichtbarkeit durch den aktuellen Personalisierungsbereich der Seite bestimmt. Ein dynamisch hinzugefügtes Steuerelement ist freigegeben, wenn sich die Seite im freigegebenen Bereich befindet. Wenn sich die Seite im Benutzerbereich befindet, handelt es sich bei dem Steuerelement um ein Benutzersteuerelement.

Ein drittes wichtiges Konzept ist der Eigenschaftenbereich. Beim Erstellen einer personalisierbaren Eigenschaft für ein Steuerelement mithilfe des Personalizable-Attributs im Quellcode können Sie den Personalisierungsbereich für die Eigenschaft entweder auf Shared oder auf User festlegen (User ist der Standardbereich). Dadurch kann detailliert gesteuert werden, welche Eigenschaften für ein Steuerelement durch alle Benutzer und welche Eigenschaften nur durch autorisierte Benutzer personalisiert werden können, wenn der Seitenbereich auf Shared festgelegt ist.

Alles in allem bilden die Konzepte Seitenpersonalisierungsbereich, Steuerelementsichtbarkeit und Eigenschaftenpersonalisierungsbereich den Bereich von Optionen, mit denen Benutzer Webparts-Steuerelemente durch Benutzer anzeigen und personalisieren können. In der folgenden Tabelle ist zusammengefasst, wie sich Webparts-Steuerelemente verhalten, wenn sie von Benutzern in den verschiedenen Bereichen personalisiert werden.

Steuerelementsichtbarkeit	Seite im freigegebenen Bereich	Seite im Benutzerbereich
Freigegebenes Steuerelement (WebPart-Steuerelemente sind standardmäßig freigegeben)	Autorisierte Benutzer können sowohl freigegebene als auch benutzerbezogene Eigenschaften des Steuerelements für alle Benutzer personalisieren. Ein dynamisches Steuerelement (ein Steuerelement, das der Seite programmgesteuert oder aus einem Katalog von Steuerelementen hinzugefügt wird) kann von einem autorisierten Benutzer dauerhaft für alle Benutzer gelöscht werden. Ein statisches Steuerelement (ein Steuerelement, das im Markup einer ASPX-Seite deklariert wurde), kann nicht gelöscht werden. Es kann jedoch von einem autorisierten Benutzer für alle Benutzer geschlossen werden.	Einzelne Benutzer können als freigegeben eingestufte Eigenschaften nicht personalisieren. Sie können im Benutzerbereich gültige Eigenschaften personalisieren. Die Werte für diese Eigenschaften haben Vorrang vor Werten von Eigenschaften, die zugewiesen wurden, als sich die Seite im freigegebenen Bereich befand. Wenn die benutzerspezifischen Personalisierungsdaten für ein Steuerelement verloren gegangen sind oder zurückgesetzt wurden, werden die im Benutzerbereich gültigen Eigenschaften auf die Werte zurückgesetzt, die sie aufwiesen, als sich die Seite im freigegebenen Bereich befand. Einzelne Benutzer können ein freigegebenes Steuerelement nicht dauerhaft löschen. Sie können es jedoch für sich selbst schließen. Dadurch wird es dem Seitenkatalog hinzugefügt.
Benutzerbezogenes Steuerelement	Das Steuerelement kann nicht für die Seite im freigegebenen Bereich personalisiert werden, weil es noch nicht einmal auf der Seite angezeigt wird. Das Steuerelement wird nur angezeigt, wenn sich die Seite im Benutzerbereich befindet.	Einzelne Benutzer können im freigegebenen Bereich und im Benutzerbereich personalisierbare Eigenschaften des Steuerelements für sich personalisieren, weil die Steuerelementinstanz gänzlich privat ist. Einzelne Benutzer können das Steuerelement auch permanent löschen.

Freigegebenes Steuerelement (WebPart-Steuerelemente sind standardmäßig freigegeben)

Autorisierte Benutzer können sowohl freigegebene als auch benutzerbezogene Eigenschaften des Steuerelements für alle Benutzer personalisieren.

Ein dynamisches Steuerelement (ein Steuerelement, das der Seite programmgesteuert oder aus einem Katalog von Steuerelementen hinzugefügt wird) kann von einem autorisierten Benutzer dauerhaft für alle Benutzer gelöscht werden.

Ein statisches Steuerelement (ein Steuerelement, das im Markup einer ASPX-Seite deklariert wurde), kann nicht gelöscht werden. Es kann jedoch von einem autorisierten Benutzer für alle Benutzer geschlossen werden.

Einzelne Benutzer können als freigegeben eingestufte Eigenschaften nicht personalisieren. Sie können im Benutzerbereich gültige Eigenschaften personalisieren. Die Werte für diese Eigenschaften haben Vorrang vor Werten von Eigenschaften, die zugewiesen wurden, als sich die Seite im freigegebenen Bereich befand. Wenn die benutzerspezifischen Personalisierungsdaten für ein Steuerelement verloren gegangen sind oder zurückgesetzt wurden, werden die im Benutzerbereich gültigen Eigenschaften auf die Werte zurückgesetzt, die sie aufwiesen, als sich die Seite im freigegebenen Bereich befand.

Einzelne Benutzer können ein freigegebenes Steuerelement nicht dauerhaft löschen. Sie können es jedoch für sich selbst schließen. Dadurch wird es dem Seitenkatalog hinzugefügt.

Benutzerbezogenes Steuerelement

Das Steuerelement kann nicht für die Seite im freigegebenen Bereich personalisiert werden, weil es noch nicht einmal auf der Seite angezeigt wird. Das Steuerelement wird nur angezeigt, wenn sich die Seite im Benutzerbereich befindet.

Einzelne Benutzer können im freigegebenen Bereich und im Benutzerbereich personalisierbare Eigenschaften des Steuerelements für sich personalisieren, weil die Steuerelementinstanz gänzlich privat ist.

Einzelne Benutzer können das Steuerelement auch permanent löschen.

Wesentliche Personalisierungskomponenten

Die folgende Tabelle zeigt die beiden Komponenten der Webparts-Steuerelementreihe, die für die Personalisierung unbedingt notwendig sind. Wenn Sie die Personalisierung verwenden, haben sie immer, entweder direkt oder indirekt, mit diesen Komponenten zu tun.

Webparts-Steuerelement	Beschreibung
WebPartManager	Verwaltet alle Webparts auf einer Seite, aktiviert oder deaktiviert die Personalisierung und verwaltet den Lebenszyklus von Personalisierungsdaten. Für jede Webparts-Seite ist genau ein WebPartManager-Steuerelement erforderlich.
WebPartPersonalization	Implementiert die für das Ausführen von Personalisierungsaktionen erforderliche Logik.