Alternative für SharePoint 2007 EventReceiver für Veröffentlichungsseiten

Das mit den EventReceivern in SharePoint ist ja schon lange so eine Sache... In der 2003er Version gab es nur asynchrone Events. Diese konnte man eigentlich nur dazu benutzen um andere Daten (z.b. in externen LOB Systemem) zu manipulieren. Mit der Version 2007 kamen dann noch synchrone Ereignisse dazu, allerdings ist dessen Verwendungszweck - gemäss Microsoft - vor allem dazu gedacht, ein Ereignis (z.B. das Anlegen eines neuen SPListItems) gegebenenfalls abzubrechen.

Vielfalch ist der Anwendungsfall doch aber der, dass nicht alle Informationen Informationen eines neuen Datensatzes (um mal vom SPListItem wegzukommen) vom Benutzer eingegeben werden (sollen). Vielmehr werden diese Informationen aufgrund der Eingaben oder anderer Parameter automatisch ergänzt. Wer viel mit SharePoint entwickelt weiss, dies mit den SharePoint Ereignissen zu realisieren ist ein RItt durch die Hölle... So hat z.B. der ItemAdding (synchrone) Event zwar eine Before- und eine AfterProperties Sammlung - nur die BeforeProperties geben nichts her und Änderungen an den AfterProperties werden für Bibliotheks-Listen nicht gespeichert. Für Veröffentlichungsseiten scheiden auch die asynchronen Ereignisse aus, den diese passieren erst dann, wenn SharePoint die eigentliche Bearbeitung schon abgeschlossen hat und die Seite für den Editor wieder neu lädt. Will dieser noch einmal Speichern erhält er eine Fehlermeldung, dass die Seite in der Zwischenzeit verändert worden ist...

Glücklicherweise gibt es gerade für solche Situationen eine Alternative. Speichert man nämlich eine (Veröffentlichnungs-)Seite, so nimmt SharePoint intern die Inhalte von SPContext.Current.ListItem. Dieses Wissen eröffnet uns ganz neue Perspektiven, es muss nun ja nur noch ein Weg gefunden werden um nach dem Auslösen der Speicherung noch Einfluss auf die Inhalte des neuen oder geänderten SPListItem zu nehmen.

Glücklicherweise haben sich die Entwickler von Microsoft auf die standard ASP.NET Methoden zur Validierung von Benutzeroberflächen-Inhalten besinnt und rufen explizit Page.Validate auf, bevor sie ein SPListItem speichern. Dies erlaubt uns, auf der Seite oder in einezelnen WebControls die Validate-Methode zu überschreiben, gegenenfalls Inhalte hinzuzufügen oder zu verändern. Wir können nun also unsere Seite um eigene Controls erweitern, oder aber wir Subclass-en gleich die ganze Seite. Am Beispiel einer Veröffentlichnugsseite mit eigenen PageLayout möchte ich dies kurz exemplarisch aufzeigen:

Wir erstellen also eine Klasse, welche von PageLayout ableitet und überschreiben die Methode Validate. In diesem Beispiel schreiben wir in eine verstecktes Feld die Werte eines Multi-Lookup-Feldes für die spätere Abfrage mit einem ContentQueryWebPart.

public class MyValidatingPublishingLayoutPage : Microsoft.SharePoint.Publishing.PublishingLayoutPage
{
    ...

    public override void Validate()
    {
        if (SPContext.Current.FormContext.FormMode == SPControlMode.Edit)
        {
                SPListItem item = SPContext.Current.ListItem;

                item[CustomFieldName.MyMultiValueLookupString] =
                    GetDelimitedMultiValueLookupString(item[CustomFieldName.MultiValueLookup].ToString());
        }
        base.Validate();
    }
}

Nun müssen wir unserem PageLayout nur noch beibrigen, dass es unsere (Sub-)Class verwenden soll. Hierfür editieren wir die .ASPX Datei wie folgt:

<%@ Page Language="C#" Inherits="FirstQuad.SharePoint.UI.Publishing.Examples.MyValidatingPublishingLayoutPage,FirstQuad.SharePoint.UI.Publishing.Examples, Version=1.0.0.0, Culture=neutral, PublicKeyToken=xxxa00116c38xxx" %>

Sobald wir die Assembly sauber installiert haben erhalten wir bei jeder Speicherung einer Veröffentlichungsseite mit dem entsprechenden PageLayout unser verstecktes Feld abgefüllt - ganz ohne EventReceiver!

Selbstverständlich hat diese Methode auch Nachteile! Diese Implementation ist davon abhängig, dass die Daten effektiv über die Benutzeroberfläche erfasst werden - EventReceivers sind von der Architektur her gesehen viel tiefer und unabhängig, ob die SPListItems über die Benutzeroberfläche, die API, WebServices oder eine andere Schnittstelle verändert werden.

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