Die für mich besten Gelegenheiten, einen längeren Beitrag zu schreiben, sind wenn eine entsprechende Anforderung in einem Projekt auftaucht. Da kann man dann immer das Schreiben mit der Recherche verbinden – so auch in diesem Fall.

In diesem Post geht es um die Möglichkeiten, das SharePoint UI mit Custom Actions zu erweitern. Dazu schauen wir uns zuerst einmal an, an welchen Stellen man das SharePoint-UI mit Custom Actions erweitern kann. Custom Actions können Links, Toolbar Buttons oder Menüeinträge sein, die man dem SharePoint UI hinzufügen oder aber auch daraus entfernen kann.

In der folgenden Tabelle habe ich einmal die Erweiterungsmöglichkeiten aufgelistet. Neben den List forms (Display, Edit, New) kann man auch den sogenannten Edit Control Block (ECB) –also das Item-Kontextmenü–  und sogar die Central Administration mit Custom Actions erweitern. Auch das Site Action Menü kann mit Custom Actions erweitert werden.

(Tabelle von André Vala)

Da wir jetzt wissen, welche Teile des SharePoint UI wir mit Custom Actions erweitern können, schauen wir uns an, wie man so eine Custom Action erstellt. Wie bei SharePoint üblich werden auch Custom Actions an ein Feature gekoppelt. Das erste was wir also brauchen, ist eine Datei mit dem Namen feature.xml:

<?xml version="1.0" encoding="utf-8" ?>
<Feature Id="2CF55F2C-0A07-4a2d-BF9C-63BFDE32168D"
    Title="Feature Custom Action Feature"
    Description="My Custom Action Feature Description."
    Version="1.0.0.0"
    Scope="Site"
    xmlns="http://schemas.microsoft.com/sharepoint/">
  <ElementManifests>
    <ElementManifest Location="MyCustomAction.xml"/>
  </ElementManifests>
</Feature>

Schauen wir uns die feature.xml etwas näher an. Unter Feature Id hinterlegen wir eine neu generierte GUID (bitte nicht von irgendwo her kopieren). Title und Description sind selbsterklärend. Interessant ist dann wieder der Eintrag ElementManifest Location. Hier geben wir den Namen einer XML-Datei an, die die eigentliche Beschreibung unserer Custom Action enthält.

Da es eine ganze Menge an möglichen Locations gibt, gibt es auch nicht die eine elements.xml. Bedeutet: je nach Location unterscheiden sich die einzelnen Parameter in der XML-Datei. Eine gute Übersicht findet sich bei MSDN oder im Blog von André Vala.

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <CustomAction
    Location="EditControlBlock"
    RegistrationType="List"
    RegistrationId="101"
    Title="My Custom Action"
    Description="My Custom Action Description">
    <UrlAction Url="http://sharepointcommunity.de/blogs/owirkus"/>
  </CustomAction>
</Elements>

In meinem einfachen Beispiel möchte ich eine Custom Action in den EditControlBlock (also das Item Kontextmenü) einer Dokumentlibrary einbauen (daher die RegistrationId = 101). Interessant an der obigen elements.xml ist die Zeile UrlAction. Hier sieht man, wie die Sache mit den Custom Actions funktioniert. Man trägt im SharePoint UI über eine Custom Action einen Link oder einen Button ein und dahinter verbirgt sich immer eine URL – etwas anderes ist nicht möglich! In meinem Beispiel soll die CustomAction die Startseite meines Blogs im Browser anzeigen.

Die Installation läuft ab wie üblich. Am besten wäre es natürlich, beide Dateien z.B. mit dem WSPBuilder in eine Solution zu verpacken. Hier in meinem Beispiel möchte ich aber den manuellen Weg wählen. Zuerst erstellen wir also ein Verzeichnis mit dem Namen CustomActionDemo und dorthin kopieren wir die beiden XML-Dateien. Die erste muss feature.xml heissen, die zweite –weil in der feature.xml so festgelegt– mycustomaction.xml. Das Verzeichnis mit beiden Dateien kopieren wir nun in den 12-Hive in TEMPLATE\Feature. Danach können wir das Feature mit STSADM wie gewohnt installieren:

stsadm –o installfeature –filename customactiondemo\feature.xml

Wenn das geklappt hat können wir das Feature aktivieren:

stsadm –o activatefeature –filename customactiondemo\feature.xml –url http:\\mossdemo01  (die Url muss natürlich angepasst werden)

Wenn alles geklappt hat, sollte unser Feature in den Site Collection Features so auftauchen:

Und im SharePoint bei einer Dokumentbibliothek sieht das Ganze dann so aus:

So kann man also eine Custom Action mit einer Dokumentbibliothek verbinden. Das ist sicherlich gut um die Grundlagen von Custom Actions zu erklären, aber im praktischen Projekteinsatz ist die starre Verbindung zwischen Liste und Custom Action nicht immer sinnvoll. Da ich ein großer Fan von ContentTypes bin, habe ich mir gleich auch noch angesehen, wie man eine Custom Action mit einem ContentType verbinden kann. Prinzipiell ist die Vorgehensweise ähnlich, wir müssen nur die Einträge für RegistrationType und RegistrationId verändern.

Das sieht dann z.B. so aus:

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <CustomAction
    Location="EditControlBlock"
    RegistrationType="ContentType"
    RegistrationId="0x010100D894B664B7852642BC207CEBD680600D"
    Title="My Custom Action"
    Description="My Custom Action Description">
    <UrlAction Url="http://sharepointcommunity.de/blogs/owirkus"/>
  </CustomAction>
</Elements>

Schlecht an der Konfiguration ist leider nur, dass man den ContentType über seine GUID referenzieren muss. Eine Referenzierung über den Namen klappt leider nicht! Wenn man –wie ich– ContentTypes gern über die SharePoint-Oberfläche (und weniger über Code) anlegt, dann hat man in diesem Fall leider zwei Probleme: wie komme ich an die GUID eines ContentTypes, den man über die Oberfläche angelegt hat und wie verhält sich die Sache, wenn ich vom Entwicklungssystem auf das Produktivsystem bzw. auf das Testsystem übertrage?

Erste Frage: wie komme ich an die GUID des ContentTypes? Sofern man den ContentType über die Oberfläche von SharePoint angelegt hat, gibt es meines Wissens nach nur eine Möglichkeit: aus der Statuszeile rauskopieren. Zugegeben – sehr unschön, aber immerhin möglich. Man lässt sich dazu die Site Content Type Gallery anzeigen und schiebt vorsichtig den Mauszeiger auf den Namen des ContentType – aber nicht klicken!!! In der Statuszeile wird jetzt die GUID angezeigt. Das sieht dann ungefähr so aus:

Der lange String hinter ctype= ist die GUID des ContentTypes. Wie gesagt – etwas unschön das Ganze, aber wenn jemand eine bessere Möglichkeit kennt, wäre ich froh über einen Hinweis in einem Kommentar zu diesem Post.

Zur zweiten Frage: die Übertragung vom Entwicklungssystem auf das Produktivsystem bzw. das Testsystem ist natürlich in diesem Fall etwas heikel. Sofern bei der Übertragungsmethode die GUID des ContentTypes nicht geändert wird, wird die Custom Action weiterhin funktionieren. Besser ist es, den ContentType programmatisch zu erzeugen. Auf diese Weise kann man sicherstellen, dass die GUID des ContentTypes weiterhin gültig bleibt. Allerdings gibt es durchaus Situationen, in denen der Weg über die Programmierung nicht funktioniert – z.B. wenn der ContentType bereits existiert.

Soweit zu den Basics von Custom Actions! Das Hauptproblem bei Custom Actions ist meiner Meinung nach das Erstellen der elements.xml. Je nach Location ändern sich die folgenden Parameter. Hier hilft dann wirklich nur noch ein wenig Experimentieren und ein Blick in die MSDN. Das zweite was man sicher vorher überlegen sollte: kann ich die Aktion, die durch die Custom Action ausgeführt werden soll, über einen Link ansprechen? Wenn ja, wie implementiere ich die auszuführende Aktion? Da man als Url nicht unbedingt einen festen Wert (wie in meinem Beispiel), sondern auch lokale Pfade verwenden kann, gibt es hier einige Möglichkeiten der Umsetzung.

Weitere Informationen über Custom Actions finden sich in der MSDN:

http://msdn.microsoft.com/en-us/library/ms460194.aspx

Nachtrag: man kan seine eigene Custom Action natürlich auch mit einem kleinen Icon versehen. Im 12-Hive unter TEMPLATE/IMAGES gibt es eine ganze Menge mitgelieferter Icons. Auf diese Icons kann man zurückgreifen. Dazu fügt man einfach folgende Zeile in die Datei elements.xml zwischen die CustomAction-Tags ein:

ImageUrl="/_layouts/images/lg_ICMSG.gif"

Nachtrag: Danke an Andi Fandrich für den Hinweis: klar – aus der URL im Browser kann man sich die GUID des ContentTypes auch herauskopieren. Das geht sogar besser, weil man hier mit Cut and Paste arbeiten kann. Das Ganze sieht dann so aus: