Thursday, June 12, 2008

Provisioning Site Collections, Portal Style

10/1/2007
Provisioning Site Collections, Portal Style
Have you ever needed to create a site collection that consists of more than one site? This is a very common scenario, and in fact this very site is an example. This site collection started as a blank site and a sub site was added using the blog site template. MOSS can create a site collection using the Collaboration or Publishing site templates and in both cases, sub sites are involved.
This is accomplished using a Provisioning Provider. The examples in this article apply to MOSS, but if you are using WSS I will talk about how to extend WSS at the bottom.
As in all examples of custom site templates that don't involve the save as site template, *.stp, sort of site templates, this one starts with a web template file in the 12 hive's \TEMPLATE\1033\XML (or not 1033 if you are a different locale). For this example I have created an xml file called WEBTEMPProvisioningExample.xml that contains the following:






This file says that we have a new site definition that will display in the eLumenotion group called 'Team Site with Blog Sample'. It points to a second file, Provisioning.xml that is located in the 12 hive's \TEMPLATE\SiteTemplates\eLumenotion\XML folder that contains the following:


siteDefinition="STS#0"
displayName="Team Site with Blog"
description="A root level team site with a blog." >

siteDefinition="BLOG#0"
displayName="A Blog"
description="A site for a person or team to post ideas, observations, and expertise that site visitors can comment on." />



The result is that when a user chooses to create a new site collection, MOSS invokes the Microsoft.SharePoint.Publishing.PortalProvisioningProvider class to read in the file specified by the ProvisioningData attribute and create the Sites and webs. And the result is a team site with a blog as a sub site.
It's unfortunate that this handy little class, PortalProvisioningProvider, is in an assembly that doesn't come with WSS, but it is pretty simple, and the provider model makes creating your own close to trivial.
All you need is a class based on SPWebProvisioningProvider. This abstract class defines a single method that accepts a SPWebProvisioningProperties that contains the SPWeb at the root of the new site collection and a string that has the path to the file containing the rest of the provisioning instructions that contains anything you want!
So, what could you do with an implementation of SPWebProvisioningProvider? Well, right off the top of my head you could:
Create a collection of subsites.
Configure any arbitrary aspect of the site through code.
Add and activate features.
Deactivate features.
Create site columns, content types, and lists.

You get the idea. Basically anything that you could do through the object model is possible. This is the equivalent of a feature receiver for a site template.
I personally don't think you should use this as an alternative to schema xml, because no one can peer into your dll short of reflector or its equivalent, but if you wanted to create a third party solution that was obfuscated or if you just can't figure out the xml definitions and have to show something tomorrow or be fired, it might not be the worst thing in the world.

No comments: