Weiterleitung in SharePoint mit Event Handler realisieren

​​Sobald man in SharePoint 2010 oder SharePoint 2013 ein neues Item erstellt, wird man standardmäßig auf die Ansicht weitergeleitet, die man zuletzt geöffnet hatte. Jedoch muss man diesen Mechanismus ab und zu aufbrechen, weil der Benutzer auf eine bestimmte Seite weitergeleitet werden soll (Beispielsweise auf die Display-Form des gerade neu erstellten Items).

Hierzu stehen mehrere, verschiedene Lösungen zur Verfügung. Nachfolgend wird die Weiterleitung in SharePoint via Event Handling näher beleuchtet und die unterschiedliche Handhabung bei synchronen und asynchronen Vorgängen:

  1. „ItemAdding“ (synchron)
  2. „ItemAdded“ (asynchron)

Weiterleitung beim synchronen Event „ItemAdding“

Die erste Möglichkeit, die auch im Netz propagiert wird, ist ein Event Handler, der an den Event „ItemAdding" angehangen wird.  Innerhalb des „ItemAdding" Events steht der HttpContext zur Verfügung. Der HttpContext wird benötigt um die Weiterleitung einzurichten, was aus den zwei Methoden ersichtlich wird:

  • SPUtility.Redirect    (link zu MSDN)
  • HttpContext.Response.Redirect    (link zu MSDN)

SPUtility.Redirect erfordert den HttpContext als einen Übergabeparameter, wohingegen die zweite Methode, HttpContext.Response.Redirect, aus dem HttpContext hervorgeht. Das macht diese Lösung sehr einfach zu implementieren, jedoch gibt es einen gewaltigen Nachteil. Im „ItemAdding" Event wurde das Element noch nicht erstellt. Daher würde eine Weiterleitung den Vorgang der Erstellung abbrechen. Um dieses Problem zu umgehen, muss im Code das Item manuell nochmals unter Verwendung der afterProperties angelegt werden. Dabei gilt die Faustregel „je weniger Metadaten desto besser“. Wenn SharePoint für das Element zusätzlich versteckte Felder befüllt hat, müssen diese zwangsläufig auch in dem Event mit befüllt werden. Das kann sehr problematisch werden, wenn man kein herausragendes und tiefgreifendes SharePoint-Wissen mitbringt.​

Weiterleitung beim asynchronen Event „ItemAdded“​

Die zweite Möglichkeit ist es, sich an den Event „ItemAdded" anzuhängen. Der klare Vorteil hiervon ist, dass das Element schon angelegt ist. Man spart sich also das manuelle Anlegen und umgeht damit eine mögliche Fehlerquelle. Dennoch gibt es leider auch einen Nachteil: Der Event Handler ist standardmäßig asynchron. Durch das asynchrone Verhalten geht der HttpContext verloren, was dann erstmal keine Weiterleitung mehr zulässt. Dieses lässt sich allerdings leicht umgehen, in dem der Event Handler per Option (link zu MSDN) synchron geschalten wird. Der HttpContext steht dadurch wieder zur Verfügung.

Anschließend kann einfach auf dem oben erläuterten Weg eine Weiterleitung eingebaut werden. Dazu ist es nur nötig, im Konstruktor des Event Handlers den HttpContext in einer Variablen zwischen zu speichern. Danach kann man den Benutzer mit Hilfe des Kontextes auf die gewünschte Seite weiterleiten.

​​blg-article-event-handler-inside-01.png

Besonderheit in SharePoint 2013​

Für SharePoint 2013 gilt dennoch eine zusätzliche Regel: Der ListForm-Webpart der entsprechenden Liste muss in der NewForm.aspx angepasst werden. Wichtig dabei ist, dass der CSR-Renderingmodus dieses Webparts unter der Kategorie „Verschiedene" auf „Server rendert (ServerRender)" geschaltet wird, damit es funktioniert. ​

blg-article-event-handler-inside-02.png

Im Vergleich ist die erste Methode einfacher zu implementieren aber der Umstand, das Element selbst anzulegen, macht sorgfältige Arbeit zur Pflicht. Bei der zweiten Methode entfällt die komplette Handhabung des Elements.​

​​​

Comments