SharePoint für Entwickler (Teil 3)
Kommentare

Das eigentlich Spannende daran ist die neue „F5 Experience“, wie sie Microsoft großspurig verkündet. Dahinter verbirgt sich nichts weiter, als dass es jetzt möglich ist, den Debugger wie bei einer klassischen

Das eigentlich Spannende daran ist die neue „F5 Experience“, wie sie Microsoft großspurig verkündet. Dahinter verbirgt sich nichts weiter, als dass es jetzt möglich ist, den Debugger wie bei einer klassischen ASP.NET-Anwendung zu benutzen. Das sieht einfacher aus als es ist, und die Zeit, die vom Start bis zum Erreichen eines Unterbrechungspunkts vergeht, untermauert den Eindruck. Tatsächlich besteht eine SharePoint-Applikation aus einigen Bausteinen, die erst erstellt, verteilt und aktiviert werden müssen. Eine Solution besteht mindestens aus einem Solution-Paket, dem WSP und optional einem Feature, das in der Verwaltung der Site aktiviert werden kann. Sie können im Code des Features unter anderem auf Aktivieren oder Deaktivieren reagieren. Ist alles verteilt, muss das Feature aktiviert werden, was standardmäßig der Fall ist. Die Assembly mit dem Code der Seite muss schlussendlich in den GAC kopiert werden. Bis die Seite geladen und der Worker-Prozess an den Debugger angehängt werden kann, vergeht also einige Zeit. Wenn Sie eine größere Applikation bauen, die möglicherweise Dutzende Seiten, mehrere Features und Assemblies umfasst, kann jeder Druck auf F5 zum Geduldsspiel werden. Freilich ist auch das eine Art „Experience“.

Vorerst soll aber an einer einfachen Seite das Prinzip gezeigt werden. Entscheidend für Applikationsseiten ist die Basisklasse LayoutsPageBase. Diese Klasse leitet indirekt von Page ab und stellt damit alles bereit, was Sie von ASP.NET bereits kennen. Abbildung 2 zeigt die Abhängigkeiten.

Abb. 2: Die Basisklasse für Applikationsseiten
Abb. 2: Die Basisklasse für Applikationsseiten

Der Vorteil besteht in der sofortigen Verfügbarkeit der wichtigsten Basisobjekte in SharePoint – die Site vom Typ SPSite und das aktuelle Web als SPWeb. Die wichtigsten Methoden und Eigenschaften zeigt Tabelle 1.

Mitglied Aus Basisklasse Beschreibung
GetResourceString UnsecuredLayoutsPageBase Zugriff auf Ressourcen
StopRequestIfClientIsNotValid UnsecuredLayoutsPageBase Prüft, ob der Client noch verbunden ist
Site UnsecuredLayoutsPageBase Die aktuelle Site (SPSite)
Web UnsecuredLayoutsPageBase Das aktuelle Web (SPWeb)
CheckRights LayoutsPageBase Prüft die aktuellen Rechte
MakeImageUrl LayoutsPageBase Erstellt den URL zum Zugriff auf den Bildpfad

Tabelle 1: SharePoint-spezifische Eigenschaften und Methoden der Basisklasse

LayoutsPageBase sichert zudem eine Prüfung der Zugriffsrechte ab, während die Basisklasse UnsecuredLayoutsPageBase sich dafür nicht zuständig fühlt und deshalb nur für den anonymen Zugriff in Frage kommt. Eine fertige Applikationsseite hat dann etwa die in Listing 1 gezeigte Struktur.

<%@ Assembly Name="Microsoft.SharePoint, ..." %>
<%@ Page Language="C#" MasterPageFile="" 
         Inherits="Microsoft.SharePoint.WebControls.LayoutsPageBase" %>
<%@ Import Namespace="Microsoft.SharePoint" %>



 ...


 ...


 ...
  

Listing 1

Das Inherits-Attribut zeigt auf die bereits erwähnte Basisseite. Die Platzhalter leiten sich aus der verwendeten Master-Seite her. Wenn Sie anfangen, reichen vier Bereiche, um brauchbare Resultate zu erzielen. Eine vollständige Übersicht finden Sie beispielsweise in [2]. Die Steuerung der Zugriffsrechte erfolgt teilweise durch Überschreiben bestimmter Eigenschaften. So können Sie erzwingen, dass der Benutzer Administratorrechte hat. Das passiert in einer eigenen Basisseite, die ihrerseits von LayoutsPageBase erbt:

public partial class MyPageBase : LayoutsPageBase { protected override bool RequireSiteAdministrator { get { return true; } } }

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -