|
|
|
|
|
|
How To Use Site Definitions in SharePoint
Go to page: 1 2
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.
|
Intranet Journal's Tutorials |
|
Managing Editor |