Wir bieten SharePoint und .NET
Kompetenz, Erfahrung und Know-How:
"1stQuad guaranteed."

Diesen Blog abonnieren Diesen Blog abonnieren.

Aktuelle Posts

Quick-Tipp: Publishing Site Settings
Update: Dynamisches Wiki Inhaltsverzeichnis
Chart Part für SharePoint 2010
SharePoint Content DB Migration -> Access denied
Konfigurieren von „Gefällt mir“ und Kategorien und Notizen

Archiv

Januar 2012 (4)
Dezember 2011 (2)
November 2011 (10)
September 2011 (3)
August 2011 (7)
Juli 2011 (1)
Juni 2011 (3)
Mai 2011 (6)
April 2011 (5)
März 2011 (8)
Februar 2011 (8)
Januar 2011 (4)
Dezember 2010 (5)
November 2010 (7)
September 2010 (6)
August 2010 (2)
Juli 2010 (11)
Juni 2010 (13)
Mai 2010 (11)
April 2010 (4)
März 2010 (6)
Februar 2010 (2)
Januar 2010 (6)
Dezember 2009 (4)
November 2009 (13)
Oktober 2009 (17)
September 2009 (2)
Juli 2009 (2)
März 2009 (2)
Januar 2009 (1)

1stQuad ist Microsoft Certified Gold Partner und bietet SharePoint und .NET Produkt- und Projekt-Kompetenz, -Erfahrung und -Know-How für Entwicklung, Architektur, Beratung, Schulung, Training und Kurse in Schweiz sowie Deutschland und Östereich.

1stQuad ist MatchPoint Partner und bietet MatchPoint Produkt- und Projekt-Kompetenz, -Erfahrung und -Know-How für Entwicklung, Architektur, Beratung, Schulung, Training und Kurse in Schweiz sowie Deutschland und Östereich.

1stQuad ist Nintex Partner und bietet Nintext SharePoint Workflows Produkt- und Projekt-Kompetenz, -Erfahrung und -Know-How für Entwicklung, Architektur, Beratung, Schulung, Training und Kurse in Schweiz sowie Deutschland und Östereich.

1stQuad ist Balesio Gold Partner und bietet SharePoint FILEMinimizer Produkt- und Projekt-Kompetenz, -Erfahrung und -Know-How für Entwicklung, Architektur, Beratung, Schulung, Training und Kurse in Schweiz sowie Deutschland und Östereich.

1stQuad Solutions ist Kentico Certified Solution Partner und bietet Produkt- und Projekt-Kompetenz, -Erfahrung und -Know-How für Entwicklung, Architektur, Beratung, Schulung, Training und Kurse in Schweiz sowie Deutschland und Östereich.

Blog > September 2009

WebPart Entwicklung: Achtung mit WebPart.ID und StorageKey

Learning by doing: Obwohl der ASP.NET WebPart das setzten einer individuellen ID für einen WebPart zulässt unterstützt SharePoint dies nicht. Denn: Bei SharePoint sind die ID-Eigenschaft und der StorageKey eng gekoppelt. Dieser Beitrag zeigt die Zusammenhänge und hilft hoffentlich im Falle eines Falles viel, viel Zeit zu sparen.

Veröffentlicht am 30.09.2009 12:32:10 von Michael Hofer mit 0 Kommentar(en)

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:

...
WebPart webPart =webPartManager.ImportWebPart(xmlReader, out errorMessage);
...
webPartManager.AddWebPart(webPart, zoneId, zoneIndex);
...

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.ImportErrorMessageEigenschaftum dem WebPart eine spezielle Identität zu geben

Kommentar

Dieser Blog-Eintrag wurde noch nicht kommentiert.

Kommentar hinterlassen

Name:

Email:

Ihre URL:

Kommentare:

Sicherheitscode eingeben:

Zurück, Seite drucken