Blog

Approaches and Comparisons

Now that we've taken a look at some of the related technologies and covered some background, let's dig into the different approaches for creating templated SharePoint Sites and see what works and doesn't work for different scenarios.

Overview

Custom Site Definitions

Usage Scenario

As a SharePoint Developer+Administrator, you want to create a template for "Project Sites."  Project Sites will be created over and over again and will always contain the same base lists and libraries.  Using Visual Studio you create a Custom Site Definition, wrap it into a SharePoint Solution, and deploy it to your server.  Site Administrators can now see "Project Sites" as an available template when they create new SharePoint Sites.

Realities

• A Developer must be involved to create the required XML files and to wrap the customization into a SharePoint Solution
• A Server Administrator must be involved to deploy the custom Site Definition via Solution deployment

Pros

• Highly documented in the SDK, in books, and on the googlesphere
• Visual Studio Extensions for SharePoint have project templates to "help" you
• Allows you to take advantage of Feature Stapling (see below)
• Custom Site Definitions appear in the list of "Site Templates" that Site Administrators choose from when creating sites

Cons

• Creates a dependency in your environment
• Sites created based on your custom Site Definition will not work if you uninstall the Site Definition.  Your custom Site Definition will need to exist on your SharePoint Farm (possibly now and forever, depending on upgrade paths/etc)
• When SharePoint v-next comes out, instead of learning about new functionality and how it can positively affect your environment and business, you will be forced to learn about how to upgrade your Site Definitions into a v-next environment
• Site Templates are based on sites that were created from Site Definitions.  If you create a custom Site Definition, create a site based on that custom Site Definition, customize that site, and then save that site as a template you will only be able to use that Site Template on SharePoint environments that have your custom Site Definition
• Site Definitions can be difficult to debug during development
• Updating your custom Site Definition to contain an additional List or Library will not update sites that have already been provisioned with your Site Definition (and, is also technically unsupported)
• You will never regain the time you spent learning the ONET.XML file.  There is no other place in SharePoint where that knowledge is directly applicable

Site Templates

Usage Scenario

As a SharePoint Site Administrator, you want to create a template for "Department Sites."  You create a sample site based on the "Blank Site" Site Definition and then customize the sample site to contain the lists, libraries, and Web Parts you would like to have on each Department Site.  Once you're done, you save the site as a template and create 4 Department Sites based on your custom template.

Realities

• A Site Administrator can do this, no Developer/Server Administrator assistance or involvement is required
• Your custom Site Template can also be shared with other SharePoint Farms (as can other people's Site Templates, e.g., the Application Templates for WSS)

Pros

• Very quick and easy to create
• Portable and easy to deploy across environments (* Note the dependency above if the site was based on a custom Site Definition)
• Site Templates appear in the list of "Site Templates" that Site Administrators choose from when creating sites
• No Dependencies based on your Site Template's .stp file.  If a site is created based on your Site Template and then you remove your template from the Server's Site Gallery, your site instance will still work

Cons

• Not every customization is saved - I have not yet seen a definitive list of what works and doesn't work when you save a Site Template but I do know that some things do not come over as customized.
• Bugs / unexpected behavior should be expected with heavily configured sites (Web Part properties, custom Views, etc)
• Any customized pages are duplicated when a site is created based on a Site Template
• If you updated a page in SharePoint Designer
• If you applied a Theme (that's right - all those images and .css files)
• Site Templates cannot really be debugged as they are built using SharePoint's Web Interface

Feature Stapling

Usage Scenario

As a SharePoint Developer+Administrator you want to create a template for "Project Sites."  You know that the definition of a "Project Site" is going to evolve over time so you want to make it as flexible as possible.  You decide to use Feature Stapling and to implement your site customizations as custom code wrapped in a Feature Receiver.  Because Feature Stapling maps features to Site Definitions, you start by creating a custom "Project Site" Site Definition.  Using MSDN as your guide you create a new Site Definition by creating a copy of the "Blank Site" Site Definition.  Your "Project Site" Site Definition has its own Template Name and so it can now be targeted for Feature Stapling.  You wrap your Site Definition, Features, and Feature Receiver code into a SharePoint Solution and deploy it to your server.  Site Administrators can now see "Project Sites" as an available template when they create new SharePoint Sites.

Realities

• A Developer must be involved to create the required Features and Receivers and to wrap the customizations into a SharePoint Solution
• A Server Administrator must be involved to deploy the customizations via Solution deployment

Pros

• Implementation can be (supportably) updated by deploying an updated Feature Receiver  (existing sites would not be updated by default but the feature could be designed to allow for re-activation via script/etc)
• No need to customize the Site Definition or the ONET.XML file.  Your knowledge is focused on Object Model development which can be reused in other areas of SharePoint Development
• Easier debugging because you can simply activate a feature to test your site customization logic (as opposed to creating an entire site)
• Custom Site Definitions appear in the list of "Site Templates" that Site Administrators choose from when creating sites

Cons

• You are still creating a dependency because of your custom Site Definition (required to target specific types of sites)
• You may have to dig deeper into the object model than you'd like to create things like custom views, etc (which, at first glance, look easier with Site Definitions)
• You may run into race conditions if dealing with things that are provisioned as part of your Site Definition.  You would potentially have to create a test for race conditions in your Feature Receiver or else use the ExecuteUrl property as an alternative for those customizations.  For example:
• A Site's default.aspx page is provisioned by most Site Definitions.  Your Feature Receiver may get kicked off before the page gets fully provisioned
• Your base Site Definition could contain a List.  If your Feature Receiver expects that list to be there, again your Feature Receiver may get kicked off before the list gets fully provisioned

Programmatic Site Creation

Usage Scenario

As a SharePoint Developer+Administrator you want to develop a way to consistently create "Project Sites."  You have identified a parent site that will contain children "Project Sites" and you have identified what lists, libraries, and Web Parts make up a "Project Site."  You create a custom Web Part that creates a site using one of the out of the box Site Definitions and then programmatically add lists, libraries, and Web Parts to the newly created site.  You wrap your custom Web Part in a SharePoint Solution and deploy it to your server.  Users that want to create a "Project Site" are required to use your Web Part to create "Project Sites."

Realities

• A Developer must be involved to create the required Site Definition, Features, and Receivers and to wrap the customizations into a SharePoint Solution
• A Server Administrator must be involved to deploy the customizations via Solution deployment
• Because the approach uses a non-standard Site Creation process, users could be confused and may:
• not know where to go to create project sites
• create sites that don't use the correct "template"

Pros

• Complete control without dependencies
• No need to customize the Site Definition or the ONET.XML file.  Your knowledge is focused on Object Model development which can be reused in other areas of SharePoint Development

Cons

• You may have to dig deeper into the object model than you'd like to create things like custom views, etc (which, at first glance, look easier with Site Definitions)
• User Experience is non-standard

Summary

It is clear that there are plusses and minuses to each of these solutions.  In my next post I'll talk about how you can use pieces from each solution (and a little something new) to create templated SharePoint Sites using my recommended Best Practice.