Site Definitions versus Site Templates

Autor: Urs BertschyMicrosoft liefert in den Windows SharePoint Services 3.0 (WSS 3.0) gleich eine ganze Palette solcher Vorlagen, zum Beispiel für Team Sites, Wikis, Blogs oder Meeting Workspaces. Im grossen Bruder Office SharePoint Server (MOSS 2007) kommen weitere Templates für Publishing-Sites (für klassische Intranet- oder Internet-Auftritte), Report Center, Site Directories und andere mehr hinzu. Trotz des üppigen Angebots reichen die mitgelieferten Vorlagen selten aus, um die oft sehr individuellen Bedürfnisse der Anwender abdecken zu können. Oft werden spezielle Menüeinträge, Listen, Dokumentvorlagen, Workflows oder Webseiten mit vorkonfigurierten Webparts benötigt.SharePoint erlaubt es, die gemachten Änderungen in Vorlagen zu packen und diese den Anwendern zum Erzeugen von eigenen Sites - im Entwicklerjargon könnte man hier auch von Instanzieren sprechen - zur Verfügung zu stellen (Abbildung 1). Für das Erstellen solcher Sitevorlagen bietet SharePoint mit Site Templates, Site Definitions oder Features unterschiedliche Verfahren und Ansatzpunkte an. Abbildung 1: Auf Basis von Sitevorlagen können SharePoint Sites für spezifische Anwendungen vorkonfiguriert werden Site Templates - einfach, aber mit EinschränkungenDie einfachste Variante eine Vorlage für eine SharePoint Site zu erstellen, ist die Verwendung von Site Templates (Erweiterung .stp). Bei diesem Verfahren [1] werden die gewünschten Anpassungen im Prototyping-Verfahren direkt in einer vorhandenen SharePoint-Site über das Web-Interface vorgenommen. Anschliessend wird die Site als Template in der Vorlagenbibliothek abgespeichert (Abbildung 2). Dabei wird die Differenz zwischen der Site Definition, auf der die Site ursprünglich beruht, und der neuen Site abgespeichert. Beim Erstellen von neuen Sites steht den Benutzern dann das Template in der in Abbildung 1 gezeigten Vorlagenauswahl zur Verfügung. Die Vorteile dieses Verfahrens liegen auf der Hand: Die Definition von Site Templates kann problemlos von Site Administratoren oder Power Usern durchgeführt werden, ohne dass auf ein Entwickler zurückgegriffen werden muss. Ausserdem benötigt man für das Deployment (solange ein Template nicht zwischen verschiedenen Umgebungen verschoben werden muss) keinen Zugang zur Serverfarm. Site Templates sind allerdings weniger performant als Site Definitions und leiden vor allem bei grösseren Anpassungen an Fehleranfälligkeit. Ausserdem ist das Funktionsangebot bei den Site Templates eingeschränkt. So kann man beispielsweise keine eigenen Content Types erstellen oder Änderungen an Menüeinträgen vornehmen. Als Faustregel gilt: Nur was über das Webuser-Interface angepasst werden kann, lässt sich auch mit Site Templates abbilden. Abbildung 2: Bestehende Sites lassen sich als Vorlage abspeichern Site Definitions - volle KontrolleWeit mehr Möglichkeiten als Site Templates bieten Site Definitions [2]. Dabei handelt es sich im Wesentlichen um aus XML- (One.xml) und .Aspx-Dateien bestehende "Baupläne", in denen der Aufbau und die Funktionalität der Site beschrieben wird. Die oben erwähnten mitgelieferten Vorlagen von SharePoint basieren ausschliesslich auf Site Definitions. Das Verändern dieser Original-Vorlagen ist absolut tabu (ausser via Features, siehe unten). Stattdessen können Entwickler eigene, sogenannte Custom Site Definitions erstellen und damit praktisch alle Funktionen einer SharePoint Site anpassen oder erweitern. Allerdings sind auch Custom Site Definitions einigen Einschränkungen unterworfen. Die kritischste dabei ist, dass eine Site Definition nicht mehr verändert werden darf, nachdem Sites basierend auf dieser instanziert worden sind [3]. Tut man es trotzdem, kann dies in den betreffenden produktiven Sites zu Fehlfunktionen führen. Dadurch wird das nachträgliche Verändern, Aktualisieren und Warten von eigenen Vorlagen - abgesehen von einfachen Anpassungen via Features - praktisch unmöglich. Unklar ist auch, wie einfach das Übernehmen von eigenen Site Definitions auf künftige SharePoint-Versionen sein wird. Das Migrieren von Site Definitionen von SharePoint 2003 auf 2007 war beispielsweise mit erheblichen Problemen behaftet. Durch die bessere Architektur der Sitevorlagen in SharePoint 2007 dürfte der Upgrade auf "SharePoint 2010" (SharePoint 14) allerdings nicht mehr ganz so umständlich werden. Solange aber noch keine konkreten Informationen über den nächsten Release vorliegen, bleibt hier nach wie vor ein Unsicherheitsfaktor bestehen.Features - Funktionspakete Ein weiterer Weg, die Funktionalität von Sites anzupassen, führt über die sogenannten Features [4]. Im SharePoint-Universum handelt es sich bei einem Feature um XML-Definitionen und Files (.Aspx, Grafiken etc.), die bestimmte SharePoint-Erweiterungen wie Menüeinträge, Workflows, Event Handler, Listen, Datenfelder (Site oder List Columns) beschreiben. Features lassen sich nachträglich auf bestehende Sites - alternativ können Features auch auf Farm-, Web-Application- und Site-Collection-Ebene eingesetzt werden - anwenden und können bei Bedarf auch wieder deaktiviert werden. Site Definitions (auch die Originalvorlagen von SharePoint) lassen sich mit diesem Verfahren hervorragend erweitern. Einer der grossen Vorteile der Features ist, dass sie sich auch nach der Anwendung auf bestehenden Sites aktualisieren lassen. Zudem können sie durch die Definition von Abhängigkeiten miteinander verknüpft und damit zu ganzen Lösungen ausgebaut werden. So kann beispielsweise ein Hauptfeature (z.B. Projekt-Management) definiert werden, dass bei Aktivierung alle abhängigen Subfeatures mit allen für die Projekt-Management-Site benötigten Funktionen (Listen, Menüeinträge, Dokumentvorlagen etc.) einrichtet. Der Nachteil dieses Verfahrens ist, dass nach dem Erstellen einer neuen Site das Feature jeweils manuell aktiviert werden muss. Dies kann man allerdings durch die Verwendung des sogenannten Feature Stapling umgehen [5]. Dabei lassen sich Features mit einer oder mehreren Site Definitions (auch mit den mitgelieferten Vorlagen) so verknüpfen, dass sie beim Erzeugen von neuen Sites automatisch aktiviert werden. Best Practice: Site Definition mit Features kombinierenDa alle drei aufgezeigten Varianten teilweise signifikante Nachteile bieten, stellt sich die Frage nach der Best Practice beim Customizing von eigenen Sitevorlagen. Site Templates sollten wegen der oben genannten Einschränkungen nur bei einfacheren Anpassungen verwendet werden. Ausserdem sind sie in gehosteten Umgebungen, bei denen man meist keinen Zugang zu den Administrationsfunktionen des Servers hat, oft die einzige Option. Richtig eingesetzt sind Site Definitions wesentlich robuster und bieten mehr Funktionalität als Site Templates. Beim Erstellen einer eigenen Site Definition kopiert man am besten eine der Originalvorlagen (z.B. die Blank Site Definition). Dabei sollte auf direkte Anpassungen in der eigentlichen Site-Definition (One.xml) so weit wie möglich verzichtet werden. Nach dem Erzeugen von Sites auf Basis der eigenen Vorlage sind direkte Änderungen wie erwähnt ohnehin tabu. Stattdessen erweitert man diese mit Hilfe von Features. Nur so lässt sich sicherstellen, dass sich Funktionen nachträglich an bestehenden Sites und Site Definitions aktualisieren lassen.AutoreninfoUrs Bertschy ist Inhaber der auf Web- und SharePoint-Consulting/- Development spezialisierten Bertschy Informatik AG. Sie erreichen ihn via http://www.bertschy.chLinks&Literatur[1] - http://msdn.microsoft.com/en-us/library/aa979709.aspx[2] - http://msdn.microsoft.com/en-us/library/aa978512.aspx[3] - http://support.microsoft.com/kb/898631/en-us[4] - http://msdn.microsoft.com/en-us/library/ms460318.aspx[5] - http://msdn.microsoft.com/en-us/library/bb861862.aspxPeter Monadiemi