Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
+49 (0) 351/850 33-0

Stolpersteine beim Ändern von WebPart- Properties

Anforderungen an WebParts können sich im Laufe eines Projektes ändern und erfordern, dass Funktionalitäten angepasst werden müssen. Ein Beispiel hierfür kann das Erweitern, Ändern oder Löschen von WebPart- Eigenschaften sein. Stellt das Erweitern meist kein Problem dar, gilt es beim Ändern oder Löschen von WebPart – Properties jedoch einige Punkte zu beachten.

Folgendes Beispiel soll mögliche Probleme veranschaulichen:

Ein WebPart mit einer Eigenschaft „SpecialCustomer“ wird erstellt und auf einer Seite verwendet. Bei einem Update der Webseite wurde die Eigenschaft „SpecialCustomer“ in „Customer“ umbenannt.

Beim erneuten Versuch, die Seite mit dem WebPart zu öffnen, tritt plötzlich die folgende Exception auf:

Fehler beim öffnen der Seite: "WebPart Error: [ArgumentException: The serialized data is invalid.]"

Um dieses Problem zu beheben, muss der WebPart in der Lage sein,  die Daten seiner Vorgängerversionen verarbeiten zu können.  Das bedeutet im Speziellen, dass eine entsprechende Upgrade- Logik hinterlegt werden muss.

Für derartige Fälle besitzen SharpointWebParts die Eigenschaft „UnknownXmlElements“. In dieser werden alle unbekannte WebPart Properties gespeichert, die dem WebPart nicht mehr zugeordnet werden können (beispielsweise gelöschte).

Für ASP.Net WebParts sollte das Interface IVersioningPersonalizable implementiert werden. Hierdurch können verwaiste Eigenschaften bearbeitet werden. Durch Implementierung des Interfaces wird  die Methode „void Load(System.Collections.IDictionary unknownProperties)“ bereitgestellt, welche aufgerufen wird, wenn Eigenschaften eines WebParts geändert wurden. In dieser Methode besteht dann die Möglichkeit, ein entsprechendes Mapping auf die neue Eigenschaft des WebParts zu erstellen:

public new void Load(System.Collections.IDictionary unknownProperties)

{

string value = unknownProperties[„myOldProperty“].ToString();

}

Wurden die Eigenschaften angepasst, muss die Methode SetPersonalizationDirty() aufgerufen werden. Hierdurch wird ein Flag gesetzt, das anzeigt ob der ControlState des Webparts geändert wurde. Der WebPartManager wird anschließend veranlasst, die geänderten Daten zu speichern. War das Mapping auf die neue Eigenschaft erfolgreich, wird die Load Methode nicht erneut aufgerufen.

Eine Besonderheit bei WSS- WebParts ist, dass verwaiste Eigenschaften explizit aus der UnknownElements- Liste entfernt werden müssen, da diese persistiert ist und dadurch ggf. mehrfach abgearbeitet wird.

Kommentar hinterlassen


Pin It on Pinterest