|
|
|
|
|
|
|
|
Understanding SharePoint Branding Options
Robert Bogue 11/20/2007
Go to page: 1 2 3
Printer Friendly Version Site Definition Site Definitions solve the problem of site templates in that changes can be affected to them after they've been created -- but at the cost of additional work. Site definitions exist on the file system of each of the front end web server unlike site templates which exist in the content database. Each site which is created from the site definition doesn't make a copy of the page in the database, instead it stores a pointer to the site definition file. The good news is that when the page on the file system changes it changes all of the references in the database -- thus solving the problem of making changes to existing branding. In order to do a site definition, you'll first have to get the changes to the files that you want into files. You can do this from SharePoint Designer by selecting Save As and pointing to a directory. From there you have to create the support files for the site definition including the ONET.XML file which drives how the site definition is used, and the WEBTEMP*.XML file which makes the site definition show up as an option. In most cases you'll copy the STS site definition that comes with SharePoint and make your changes there rather than starting from scratch.
So with site definitions you can get the ability to modify the look and feel of the site after the site has been created, but at the cost of additional effort and with the same limitation of needing to create a separate site definition (or configuration) for each of the out of box site definitions, and they still don't solve the problem of branding the application pages. Before we get into a solution for that, we need to talk briefly about one of the features of SharePoint that works with Site Definitions in order to facilitate changes. (You can learn more about Site Definitions and how to create them in the article "SharePoint Site Definitions: Why You Need Them and How to Use Them." The article was written for 2003 but the process is largely the same between SharePoint 2003 and SharePoint 2007. You can find additional information in the SDK article "Creating a Site Definition from an Existing Site Definition".) Feature The SharePoint Feature (notice the capital F) allows you to enable and disable functionality in a site or sites. Technically speaking you're not supposed to change a site definition after it's been created, however, it's perfectly acceptable to make changes to SharePoint Features. Site definitions can automatically activate features when instances are created of them. Because of this the best way to manage changes in a site definition is to have SharePoint Features which are activated when a site is created and then allow those SharePoint Features to be changed. Features can deploy pages into a site definition -- and can also define content types, delegate controls, and a variety of other types of functionality for a site. So features are an integral part of building site definitions and a great way to manage changes over time.
(You can find out more in the SDK article "Working with Features.") Solutions When talking about site definitions, I made the point that they are files on the file system -- they're not in the content database. This means that they must be deployed to each of the front end web servers. However, that can be painful -- particularly if you have a number of SharePoint servers. However, SharePoint has a solution -- SharePoint Solutions (notice the Capital S). SharePoint Solutions, WSP files, allow you to deploy site definitions, features, web parts, and files.
Go to page: 1 2 3
Printer Friendly Version
| |||||||||||||||||||||||||||||||||||||||||
Intranet Journal's Tutorials |
|
Managing Editor |