WebPart Entwicklung: Achtung mit WebPart.ID und StorageKey

WebParts können auf einer SharePoint Seite programmatisch via SPWebPartManager oder SPWebPartLimitedManager platzieren werden. Dabei werden sie üblicherweise von WebPart-Definition-Files (.webpart oder .dwp) importiert und danach dem WebPartManager hinzugefügt:

In manchen Fällen möchte man die WebParts zusätzlich konfigurieren. In meinem Fall war es so, dass ich eine Synchronisation von WebParts erreichen wollte: Eine globale Konfiguration gibt mir vor, welche WebParts auf welcher Seite automatisch platziert werden sollen. Also habe ich nach einer Eigenschaft gesucht, in der ich eine Synchronisationskennung hinterlegen konnte. Die Idee war einfach: WebPart.ID ist vom Typ string und kann frei gesetzt werden. Was spricht also gegen folgendes:

webPart.ID = "synced_" + webPartSyncId;

Leider musste ich feststellen, dass dies im Rahmen von SharePoint NICHT funktionieren kann, obwohl das ASP.NET Framework das freie setzten einer WebPart-ID zulässt: SharePoint speichert alle Eigenschaften eines WebParts nicht wie ein "normaler" ASP.NET WebPart sonder in in den SharePoint Content-Datenbanken. Dafür wird ein sogenannter "StorageKey" verwendet. Diese erhält man z.B. über die Methode GetStorageKey der Klasse Microsoft.SharePoint.WebPartPages.SPWebPartManager.


Nachdem ich die ID-Eigenschaft einiger WebParts verändert hatte, bekam ich plötzlich seltsame Fehler des SPWebPartManagers.

Der Grund dafür ist folgender: SharePoint schreibt im JavaScript in der Methode AddChanges der Datei IE55UP.js (je nach Browsertyp verschieden) Änderungen an WebParts in ein HiddenField. Dabei wird die WebPart-ID verwendet. Server-seitig versucht der SPWebPartManager dann die gemachten Änderungen zu speichern und in der Methode ApplyChangeList wird dann aber die Methode GetStorageKeyString verwendet um den WebPart zu identifizieren...

Die WebPart.ID Eigenschaft und der SharePoint-StorageKey müssen also identisch sein. Schlimmer noch: Identisch, aber anders geschrieben, denn StorageKey ist vom Typ System.Guid, WebPartID ist ein System.String. Dies sieht dann folgendermassen aus:

StorageKey = {56D8CD8D-6D26-4f61-B80B-9AF813CF4977}
WebPart.ID = g_56D8CD8D_6D26_4f61_B80B_9AF813CF4977

Was lernen wir daraus? Da der StorageKey von SharePoint automatisch generiert wird können wir die WebPart.ID Eigenschaft nicht überschreiben, obwohl dies theoretisch über die API zugelassen ist (und ansonsten tatsächlich auch funktioniert).

Ich jedenfalls verwende (respektive missbrauche) nun notgedrungen die WebPart.ImportErrorMessage Eigenschaft um dem WebPart eine spezielle Identität zu geben


Kommentar

Kommentar hinterlassen Name: Email: Ihre URL: Kommentare: Sicherheitscode eingeben: