Intranet Journal
The online resource for intranet professionals
How To Use Site Definitions in SharePoint
8/4/2008
One of the questions that often comes up in SharePoint engagements is the question of whether you should create your own site definition or whether you should use the out-of-the-box definitions and use features to control how they appear. It is in fact a topic of some discussion between SharePoint consultants. My hope here is to illuminate the primary reasons that you should be creating site definitions -- and what reasons you shouldn't create them. Let's start our discussions about using features to modify a site definition.
Features and Site Definitions
In version 2 of the product you had to create site definitions to work around the behaviors in the out-of-the-box site definitions. There wasn't a mechanism for adding to or removing functionality from a site definition once it was created. However, in version 3 that changed. The addition of SharePoint features allows you to add and remove functionality at will. There's virtually nothing that can't be managed through the addition of a feature especially when coupled with feature receivers.
Features can deploy pages, add menu items, remove menu items, and even do more advanced things with the use of feature receivers that allows you to run any code you want when a feature is activated on a site. Features can even be stapled so that they are automatically added to new sites that are created.
As a point of fact, most of the out of the box functionality was moved into features. The site definitions reference features that are automatically added to the created site through feature dependencies in the site definition. One of the reasons that you should use features in SharePoint is because you can change and redeploy features, however, once you've created the first site from the site definition you shouldn't modify that site definition for any reason.
Making the argument for the Site Definition
If features are so great with their ability to address virtually every menu item, the ability to add new pages, and so on why wouldn't someone build everything as features and leverage the existing site definitions. There are two answers: Cleanliness and differentiation.
Cleanliness
If you've had a chance to look at the output of SharePoint using one of the out of the box site definitions you may have noticed that they're not the cleanest HTML output. You'll notice all sorts of extra stuff in the templates that isn't going to add much value. In fact it may make your job of branding your site more difficult -- and it will certainly make getting an accessible site more difficult. What does this have to do with the site definitions? Well the site definition is where the master page, web part pages, and in MOSS, where the content pages come from. If you don't like the output of the HTML you're going to be redoing these pages anyway.
Sure you can do that from a feature, however, then you have to consider the possibility that someone may accidentally reactivate one of the out of the box features and overwrite your hard work to make the page branding work or to make the page more accessible.
By creating your own site definition you have less chances for issues related to user deactivating features that they shouldn't.
Differentiation
One of the challenges with working with large numbers of sites in SharePoint is just determining what the site is supposed to be from code. Sure the user can quickly tell the difference between a Six Sigma site and a budgeting site, but how do you determine which type of site it is from code?
If you're using site definitions for the major categories of sites in your organization you can easily determine what kind of a site an instance is by just reviewing the SPWeb.WebTemplate or SPWeb.WebTemplateId properties. These fields allow you to see which site definition a site was created from.
There is no other named property that allows you to differentiate the type of site. These properties can be used to clearly identify which sites are your special sites -- ones with special code or special rules -- and which ones are out of the box collaboration sites.
It should be noted that it's possible, without implementing a site definition, to differentiate sites from one another. Each site has a property bag associated with it. It is possible to insert an entry into this property bag about what the site is supposed to be. In fact, I've used this strategy in certain circumstances, however, if you're using properties a lot you'll find that it's inconvenient to have such an important system property stored along with user supplied information.
Implementing Site Definitions
In an organization it makes sense to develop a minimal site definition that contains all of the basic elements that are required and make copies of this base site definition for every type of site that you wish to differentiate. This minimizes the work that must be done for each site definition while simultaneously supporting a clean solution.
Creating your own site definition isn't that difficult. You can start with the Minimal Publishing Site which is available from the Features project on Codeplex or download the code from Andrew Connell's book Professional SharePoint 2007 Web Content Management Development: Building Publishing Sites with Office SharePoint Server 2007. (The Download is at http://www.wrox.com/WileyCDA/WroxTitle/productCd-0470224754,descCd-DOWNLOAD.html)
It's true that both of these examples are publishing examples, but those are the most technically challenging to create and thus are the ones that samples are most needed for.
Making Sense of it All
If you take a step back and look at the problem you'll find that you'll likely start with using features to make your modifications. You'll deploy your branding through master pages, web part pages, and page layouts. When you need to differentiate between different kinds of sites. What this means for a governance plan is that you'll likely want to offer an instance of a standard site definition -- one that has the branding and core features baked in -- to key projects in the organization so it's easy and consistent to identify which sites belong to each project.
Intranet Journal's Tutorials |
|
Managing Editor |
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Shopping | E-mail Offers | Freelance Jobs 