SharePoint Custom Site Definition Battle

Joel Oleson hat in seinem Blog einen Krieg losgetreten: den SharePoint Custom Site Definition Battle. Die Reaktionen hat er u.a. hier zusammengefasst. Er sieht berechtigte Risiken in der Upgradefähigkeit von Site Definitions und wollte deren Verwendung unter Bann stellen. Die Reaktionen waren heftig. Doch hat sich ein konstruktiver Dialog ergeben, welcher ich hier kurz wiedergeben möchte.

Alternativen

Auf die Alternativen zu Site Definitions möchte ich nur kurz eingehen, da es im SharePoint kein anderes Konstrukt gibt, mit einem Klick eine Site ab einer bestimmten Vorlage zu erstellen.

So decken z.B. Site Templates (STP Dateien) nur ca. 80% der Funktionen ab. Die restlichen 20% müssten entweder geklickt oder programmiert werden. Weder das eine noch das andere lässt aber das Herz des SharePoint Architekten höher schlagen. Wenn ab

Funktionalität

Zu SharePoint 2003/WSS v2-Zeiten standen uns bis auf Site Definitions keine anderen Möglichkeiten zur Verfügung Vorlagen für Listen, Sites, etc. abzulegen. Mit SharePoint 200//WSS v3 basieren die Site Defintions auf Features, welche das Gros der Customizations beinhalten.

Wenn Customizations (Listen Vorlagen, Listen, Content Types, etc.) in Features ausgelagert und diese an eine Custom Site Defintion gestampelt werden, spricht nichts gegen Custom Site Definitions. Falsch wäre es aber heute Site Definition auf die "alte Art" zu erstellen und alles ins ONET.XML zu packen.

Um die eigenen Features aber mit einer Site Definitions zu verbinden (Stampling), kommen wir nicht darum herum eigene Site Definitions zu erstellen.

Upgradefähigkeit

Wurde eine Site ab einer Site Definition erstellt, bleibt sie auf immer mit dieser verbunden. Da gibt es keinen Weg heraus. Niemand weiss, wie das Upgrade von SharePoint 2007 auf SharePoint v.Next in Bezug auf die Site Definitions aussehen wird. Man munkelt, dass SharePoint v.Next keine Site Definitions mehr unterstützen wird. Trotzdem wird uns Microsoft einen Weg zur Verfügung stellen, wenigstens jene Sites zu migrieren, welche ab OOB Site Definitions erstellt wurden.

Sind die eigenen Site Definitions nun bis auf die ID identisch mit den OOB Site Definitions, sollte ein Upgrade uns nicht vor grosse Probleme stellen. Dadurch, dass wir aber eine eigene ID haben, können wir unsere Features mit unserer Site Definitions verbinden.

Quintessenz

1. Erstelle eine Custom Site Definitions, wenn es notwendig ist. Auch wenn es nur darum geht, eine Site Definition mit einer eigene ID in der Hand zu halten, auf welche die Features gestapelt werden.
2. Wenn du eine Custom Site Definition erstellst, beschränk dich auf das Minimum und bleib nahe bei den OOB Site Definitions. Alles was mittels Features gelöst werden kann, soll mittels Feautres gelöst werden.

Euer Kommentar ist herzlich willkommen. David Schneider

Update Content Type with a Feature

If you deploy your Content Types with a Feature, you will run into a problem, when you would like to modify the Content Type. If you modify and redeploy the Feature, then the Site Content Type is disconnected from the List Content Type. This is because very time a Content Type is assigned to a list, a new List Content Type is created, which inherits from the Site Content Type.

If you do the modification manually you should always modify the Site Content Type. While doing via Site Settings, you have an option which force SharePoint to propagate the modification to all the List Content Types inherited from the Site Content Type.

But when you do the modification by changing the Feature, then SharePoint won't update the inherited List Content Types. There are some STSADM extensions which do this work for you (i.e. from Gary Lapointe or Søren Nielsen).

I took the Code from Søren Nielsen and put it in a FeatureActivated Event Handler. In my Content Type Feature.xml I set the ReceiverAssembly and ReceiverClass attribute. This allows you the modify the Content Type in the Feature, upgrade the WSP, deactive and finally reactive the Feature. Reactivating the Feature will change the Site Content Type. SharePoint will propagate the modification with the FeatureActivated Event Handler to all the List Content Types inherited from the Site Content Type.

If you just add some Site Columns to your Site Content Type (or delete some unused Columns), this would make your deployment and change management process much more easier. Perhaps almost as easy as the good old ALTER TABLE SQL scripts ;)

Here is the my Code. Just copy the ProcessWeb() and all the other method from Søren Nielsen's blog.

<br /> public override void FeatureActivated(SPFeatureReceiverProperties properties)<br /> {<br /> SPWeb rootWeb = null;<br /> try<br /> {<br /> // get the site collection specified<br /> rootWeb = ((SPSite)properties.Feature.Parent).RootWeb;<br /><br /> //Get the source site content type<br /> SPContentType sourceCT =<br /> rootWeb.AvailableContentTypes[ContentTypeName];<br /> if (sourceCT == null)<br /> {<br /> throw new ArgumentException("Unable to find "<br /> + "contenttype named \"" + ContentTypeName + "\"");<br /> }<br /><br /> // process the root website<br /> ProcessWeb(rootWeb, sourceCT);<br /> }<br /> catch (Exception ex)<br /> {<br /> log.Fatal(ex.Message, ex);<br /> }<br /> finally<br /> {<br /> if (rootWeb != null)<br /> {<br /> rootWeb.Dispose();<br /> }<br /> }<br /> }<br />