4.1. Site Definitions

A Site Definition is used to determine the initial look and feel as well as contain the core functionality of a site when it is provisioned. A Site Definition is defined as a collection of files that reside in a subdirectory located in the [WSS]TEMPLATESiteTemplates folder on each of the front-end web servers. The WSS v3 installer currently places this folder deep in the Program Files area, with the typical address of C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12. The rest of this chapter uses the notation [WSS] to represent this folder path.

The out-of-the-box Site Definitions supplied with WSS v3 are listed in the following table. Multiple Site Definitions within the same folder location are defined as individual configurations within Onet.xml (discussed soon). All of these are visible any time a user chooses to create a new site by clicking on the Sites and Workspaces link on the Create page accessed via the Site Actions menu. Custom Site Definitions appear here as well as WSS v3 is made aware of them. The process to create and deploy a Site Definition is demonstrated later in the chapter.

Template Name	Template Category	Location
Team Site	Collaboration	[WSS]TEMPLATESiteTemplatessts
Blank Site	Collaboration	[WSS]TEMPLATESiteTemplatessts
Document Workspace	Collaboration	[WSS]TEMPLATESiteTemplatessts
Wiki Site	Collaboration	[WSS]TEMPLATESiteTemplatesWiki
Blog	Collaboration	[WSS]TEMPLATESiteTemplatesBlog
Basic Meeting Workspace	Meetings	[WSS]TEMPLATESiteTemplatesMPS
Blank Meeting Workspace	Meetings	[WSS]TEMPLATESiteTemplatesMPS
Decision Meeting Workspace	Meetings	[WSS]TEMPLATESiteTemplatesMPS
Social Meeting Workspace	Meetings	[WSS]TEMPLATESiteTemplatesMPS
Multipage Meeting Workspace	Meetings	[WSS]TEMPLATESiteTemplatesMPS

Office SharePoint Server 2007 includes additional Site Definitions (shown in the following table) that are used to assist in providing some of the added built-in functionality used by features such as publishing, records management, reporting, personalization, and searching.

Template Name	Template Category
Document Center	Enterprise
Records Center	Enterprise
Personalization Site	Enterprise
Site Directory	Enterprise
Report Center	Enterprise
Search Center with Tabs	Enterprise
Search Center	Enterprise
Publishing Site	Publishing
Publishing Site with Workflow	Publishing
News Site	Publishing

It is very important to understand that Site Definitions are different than Site Templates. A custom Site Template is a collection of customizations applied to a site by an end user or developer that are all placed into a file with an .stp extension and stored in the Site Template gallery of the top-level site in a site collection so that they are available for use in all subsites subsequently created in that site collection. A custom Site Template consists of the differences or the "delta" between the underlying Site Definition from which the site was created and the state of the site when the custom Site Template is generated. From this definition, you can see that a custom Site Template is tethered to its underlying Site Definition; therefore, if the Site Definition is not present, the custom Site Template will not function.

Site Definitions improve performance and scalability, as they are cached in memory on the web server on startup, reduce round trips to the content database, and can be reused across multiple sites. Information is subsequently pulled from the web server's cache at runtime. Pages as well as list schema information are read from the cached files, but to the user, appear to be actual files within the physical web site. SharePoint's process of rendering a page from cache is sometimes referred to as viewing a "ghosted" (WSS v2 term) or "uncustomized" (WSS v3 term) page. The key thing to note is that the actual content of an uncustomized page resides on the file system. The row referring to an uncustomized page in the content database contains a column whose value points to the physical location of the page on the disk within the Site Definition folder on the web server.

When a page is customized, it becomes "unghosted" (WSS v2 term) or "customized" (WSS v3 term) and the changes made to the page are stored in the content database. This is a vast improvement over how "unghosted" pages were handled in WSS v2. In WSS v2, the entire page, not just the differences or delta, was stored in the content database. Subsequent requests for an "unghosted" page were served from the content database thereby resulting in a slight performance hit when compared to serving them directly from the web server's cache. This process in WSS v2 led to maintenance headaches in many cases because it was not easy, at times not possible, to revert back to the original "ghosted" or "uncustomized" page. In WSS v3, Microsoft has provided a link (see Figure 4-1) on the Site Settings page to revert a page or an entire site to its original state before any customizations were applied. Using this link simply deletes the changes that were stored in the database for that particular page or site. This is a substantial improvement over how WSS v2 handled page customization. It's now time to discuss a number of the files needed to create and support a custom Site Definition.

4.1.1. Site Definition Files

Many files can make up the structure of a Site Definition, including XML, ASPX, ASCX, and master page files as well as document template files and content files. A Site Definition must reside in an appropriately named folder in the [WSS]TEMPLATESiteTemplates folder. In addition to the preceding folder and files, a file by the name of WebTemp*.xml must also exist in the [WSS]TEMPLATE1033XML folder, where "*" should be replaced with the name of your custom Site Definition. This file specifies the configuration(s) for your custom Site Definition templates. It is read once and cached by the web application on startup.

The heart and soul of a Site Definition is the Onet.xml file. This file exists for each and every Site Definition in a SharePoint installation, and you can find it in the XML subfolder of the Site Definition folder. The main functions of this file (as described in the SDK) are listed here:

• Define the top and side navigation areas that appear on the home page and in list views.

• Specify the list definitions that are used in the Site Definition and whether they are available for creating lists on the Create page.

• Specify document templates that are available for creating document library lists on the New page, and specify the files used in the document templates.

• Define the base list types from which default WSS v3 lists are derived. Used only in the Global Onet.xml file (discussed later in this chapter).

• Specify the configurations of lists and modules that are used within Site Definitions.

• Specify WSS v3 components.

• Define the footer section used in server email.

By creating a custom Site Definition, you can tailor the available functionality used to cater to your particular business needs. Some of the possible customizations you can include in our custom Site Definition include the following:

• Specify an alternate Cascading Style Sheet (CSS) file, JavaScript file, or ASPX header file for a Site Definition.

• Modify navigation areas for the home page and list pages.

• Add a list definition as an option to the Create page.

• Add a document template for creating document libraries.

• Define a configuration for a Site Definition, specifying the lists, modules, files, and Web Parts that are included when a site is provisioned (provisioning a site is synonymous with creating a site).

We cannot stress how important it is to not modify any of the files owned by WSS v3. The only supported method of creating Site Definitions is to start from scratch by building out the Onet.xml file and other supporting files manually, or preferably (and much easier), by making a copy of one of the packaged site definitions that most closely matches your needs and modifying the copy. This method essentially guarantees that your site definition will not break any existing sites nor will it be overwritten by a service pack in the future.

The Onet.xml file contains a number of elements that together all work in tandem to provision a site as it is defined within this file. The top-level element in the Onet.xml file is the Project element, which is described in more detail in the following table.

Attribute	Description
Title	Required Text. Specifies a default name for a SharePoint site.
Revision	Optional Integer.
ListDir	Required Text. Specifies the directory to implement in new lists.
AlternateCSS	Optional Text. Used in an Onet.xml file to specify the name of an alternate cascading style sheets (CSS) file located in the [WSS]TEMPLATELAYOUTS1033STYLES directory that defines styles to use in the site definition.
CustomJSUrl	Optional Text. Alternate JavaScript file for custom scripts.
AlternateURL	Optional Text.
AlternateHeader	Optional Text. ASPX file for alternate header
DisableWebDesignFeatures	Optional Text. Blocks specific editing features that are used in Microsoft Office SharePoint Designer 2007. Possible values include the following, which can be delimited using semicolons: wdfbackup wdfrestore wdfpackageimport wdfpackageexport wdfthemeweb wdfthemepage wdfnavigationbars wdfnavigationview wdfpublishview wdfpublishselectedfile wdfopensite wdfnewsubsite

The Project element in turn contains the following elements:

• NavBars

• ListTemplates

• DocumentTemplates

• Configurations

• Modules

4.1.1.1. NavBars

Definitions for the top navigation area and the side navigation area are both contained in the NavBars element. The NavBars element can contain multiple NavBar elements, which the following table describes in more detail. A NavBar element is a header level link. When looking at the Quick Launch navigation bar on the left-hand side of the screen, this equates to the Documents, Lists, Discussions, Sites, and People and Groups links that appear in the navigation after creating a Team Site.

NavBar Attribute	Description
Body	Required Text. Contains the body of the definition for the naviga-tion bar.
ID	Required Integer. Specifies the ID of the navigation bar.
Name	Required Text. Contains the name of the navigation bar.
Prefix	Optional Text. Contains the opening tag for the table that contains the navigation bar.
Separator	Optional Text. Specifies the separator to use between items in the navigation bar.
Suffix	Optional Text. Contains the closing tag for the table that contains the navigation bar.
Url	Optional Text.

Links can be added by including any number of NavBarLink elements within any of the NavBar elements. The following table, from the SDK, outlines the attributes of the NavBarLink element. These links will appear under the NavBar elements defined above. For example, you could add a link to a Status Reports document library under the Documents header defined by its NavBar element by adding a NavBarLink element within it in the XML. This, of course, assumes that you are including a Status Report document library in your Site Definition; otherwise, the link would not be very helpful!

NavBarLink Attribute	Description
Name	Required Text. Contains the text displayed for the hyperlink.
Url	Required Text. Contains the URL for the hyperlink.

4.1.1.2. ListTemplates

List Definitions that are part of your custom Site Definition are contained within the ListTemplates element. The details surrounding the schema.xml file that is used to define a List Definition is beyond the scope of this book but can be researched at http://msdn2.microsoft.com/en-us/library/ms459356.aspx. The following table outlines the attributes of the ListTemplate element. Only BaseType, DisplayName, and Name are required attributes; the remaining ones are all optional. Many of the attributes that you see here you also see when viewing a list's settings through the SharePoint user interface.

ListTemplate Attribute	Description
AllowDeletion	Optional Boolean. TRUE to specify that lists created through the list definition cannot be deleted; otherwise, FALSE.
AllowEveryoneViewItems	Optional Boolean. TRUE to allow any user to view items in the library. The AllowEveryoneViewItems attribute is used, for example, in the Master Page gallery to give all users access to master pages.
AlwaysIncludeContent	Optional Boolean. TRUE to specify that list content be included by default when lists created through the list definition are saved as list templates in the user interface; otherwise, FALSE.
BaseType	Required Integer. Specifies the base type, or default schema, for lists created from the definition.
CacheSchema	Optional Boolean. TRUE to enable schema caching of the list when provisioning a site. The CacheSchema attribute is used, for example, in the global Onet.xml file to enable caching of the user list for the current site collection.
Catalog	Optional Boolean. TRUE to specify that the list definition is for a site gallery, a list gallery, or a Web Part gallery.
Category	Optional Text. Specifies the category with which to associate lists created through the list definition. Possible values include Libraries, Communication, Tracking and Custom Lists.
Default	Optional Boolean. TRUE to specify that new SharePoint sites will include this list.
Description	Optional Text. Provides a description of the list definition.
DisableAttachments	Optional Boolean. TRUE to specify that users can attach files to items in lists created through the list definition; otherwise, FALSE.
DisallowContentTypes	Optional Boolean. TRUE to specify that content types can be managed on lists created through the list definition; otherwise, FALSE.
DisplayName	Required Text. Specifies the display name of the list definition.
DocumentTemplate	Optional Integer. Currently unused. This is only valid in a ListTemplate element whose BaseType is set to 1 (document libraries). For future compatibility, this should either be left blank or correspond to the Type attribute of a DocumentTemplate element in the DocumentTemplates enumeration. This attribute has been deprecated in WSS v3.
DontSaveInTemplate	Optional Boolean. TRUE to exclude the content of the list when the list is saved as a custom list template or when the site to which the list belongs is saved as a custom site template through the user interface.
EditPage	Optional Text. Specifies the name of a custom form to use as the page for editing items in lists created through the list definition.
EnableModeration	Optional Boolean. TRUE to specify that content approval is enabled by default in lists created through the list definition; otherwise, FALSE.
FeatureId	Optional Text. Specifies the GUID that identifies the Feature with which the list definition is associated.
FolderCreation	Optional Boolean. TRUE to enable folder creation within the list and to specify that the New Folder command appears on the New menu in list views; otherwise, FALSE.
Hidden	Optional Boolean. TRUE to specify that the list definition is not available on the Create page for creating lists.
HiddenList	Optional Boolean. TRUE to specify that a list created from the list definition is hidden.
Image	Optional URL. Specifies a URL to an icon used to represent a list.
MultipleMtgDataList	Optional Boolean. If MultipleMtgDataList="TRUE" is specified, the list within a Meeting Workspace site contains data for multiple meeting instances within the site.
MustSaveRootFiles	Optional Boolean. TRUE to save the pages contained within a special document library that is used internally for a Meeting Workspace site when the list template is saved without content. This attribute is not intended for public use.
Name	Required Text. Specifies the internal name of the list definition. No spaces or special characters can be used. This name is also used to find the folder that contains the Schema.xml file that defines the schema in use.
NewPage	Optional Text. Specifies the name of a custom form to use as the page for creating items in lists created through the list definition.
NoCrawl	Optional Boolean. TRUE to specify that the list not be visible in search results; otherwise, FALSE.
OnQuickLaunch	Optional Boolean. TRUE to display lists created from the list definition on the Quick Launch bar.
Path	Optional Text. Specifies the name of the site definition that contains the list definition, for example, STS. This path is assumed to be relative to the 12TEMPLATE directory. The path can be directed at a features schema, for example, FeaturesAnnouncements. This attribute has been deprecated in Windows SharePoint Services 3.0.
RootWebOnly	Optional Boolean. TRUE to specify that the list created from the definition exists only in the root web site of a site collection. This attribute has been deprecated in Windows SharePoint Services 3.0.
SecurityBits	Optional Text. Defines read, write, and schema design security. Each digit in the string corresponds to the three security settings contained in the List of Lists database table. This attribute does not apply to document libraries.
Sequence	Optional Integer. Specifies the ordering priority to use for the list definition on the Create page. If Sequence is not set, the list definition shows up last in arbitrary order with any other list definitions that also lack a Sequence value. Two list definitions that specify the same sequence are sorted together in an arbitrary order.
SetupPath	Optional Text. Specifies the path to a folder in the Windows SharePoint Services setup directory (\Program FilesCommon FilesMicrosoft Sharedweb server extensions12TEMPLATE) that contains a file to be included in the list definition.
SyncType	Optional Boolean. TRUE to override the default client list type associated with a Windows SharePoint Services base template.
Type	Optional Integer. Provides a unique identifier for the list definition. This identifier must be unique within the feature, but need not be unique across all feature definitions or site definitions. This attribute corresponds to the Type attribute of the List element.
Unique	Optional Boolean. TRUE to specify that the list definition or list template can only be used to create a list during site creation and cannot be used to create a list through the object model or user interface after the site template or definition is applied. Setting this attribute to TRUE has the effect of making the list hidden so that it does not appear as an option on the Create page or on the Documents and Lists page.
UseRootFolderForNavigation	Optional Boolean. TRUE to specify that a link to the list that is displayed in Quick Launch points to the root folder so that users go to a custom welcome page, instead of to the default list view page.
VersioningEnabled	Optional Boolean. TRUE to specify that versioning is enabled by default in lists created through the list definition; otherwise, FALSE.

Note that a ListTemplate element contains two separate attributes for type; Type and BaseType. The Type attribute is used to specify a unique identifier for the list definition itself while the BaseType attribute is used to identify the base list type for the List Definition that corresponds to the Type value of one of the base list types defined in the Global Site Definition's Onet.xml file located at [WSS]TEMPLATEGLOBALXML. Within the Global Site Definition, discussed later, you will see that there are five ListTemplates defined.

• Master Page Gallery

• Users

• Site Template Gallery

• List Template Gallery

• Web Part Gallery

All of the above (with the exception of the Master Page Gallery) are only available on the root web. The ListTemplate definition for the Web Part Gallery looks like the following snippet. You can see that the RootWebOnly attribute is set to true, thereby limiting this list template to use on a top-level site.

<ListTemplate
  Name="wplib"
  DisplayName="$Resources:core,webpartgalleryList;"
  Description="$Resources:core,webpartgalleryList_Desc;"
  SetupPath="globallistswplib"
  Type="113"
  BaseType="1"
  Hidden="TRUE"
  HiddenList="TRUE"
  NoCrawl="TRUE"
  FolderCreation="FALSE"
  Unique="TRUE"
  RootWebOnly="TRUE"
  Catalog="TRUE"
  OnQuickLaunch="FALSE"
  SecurityBits="11"
  AllowDeletion="FALSE"
  Image="/_layouts/images/itdl.gif"
  DontSaveInTemplate="TRUE"
  DocumentTemplate="100" />

The following table lists the default list types. This list is handy when you are creating your own List Definitions, Site Definitions, or even event handlers which are discussed in Chapter 5.

Value	Description
100	Generic list
101	Document library
102	Survey
103	Links list
104	Announcements list
105	Contacts list
106	Events list
107	Tasks list
108	Discussion board
109	Picture library
110	Data sources
111	Site template gallery
113	Web Part gallery
114	List template gallery
115	XML Form library
120	Custom grid for a list
200	Meeting Series list
201	Meeting Agenda list
202	Meeting Attendees list
204	Meeting Decisions list
207	Meeting Objectives list
210	Meeting text box
211	Meeting Things To Bring list
212	Meeting Workspace Pages list
300	Portal Sites list
1100	Issue tracking
2002	Personal document library
2003	Private document library

It's interesting to note the lack of numbering. For example, you may notice that the number 112 is mysteriously missing from the list. While developing on this platform and writing this book, we have had plenty of time to snoop around the WSS v3 Framework. If you were to browse to any site, go to Site Settings under Site Actions and click on People and groups, you would arrive at a page representing of list of users in a particular group. If this is a new site, the group you are looking at is most likely <site> Members, where <site> can be replaced with the name of the site when it was provisioned. If you view the HTML source code of this particular page and scroll down toward the bottom, you will observer that there is a listTemplate hidden field that contains a value of 112. We leave it up to you to explore this "phenomenon" further, if it has in fact stirred your interest.

4.1.1.3. Document Templates

The DocumentTemplate element is used to define the document templates that are available on the New page when creating a document library. These templates are listed in the Document Template drop-down on the New Document Library page (see Figure 4-2). The following table outlines the attributes of the DocumentTemplate element. Only DisplayName and Type are required. You could use this section of the Site Definition to define a standard status report template that all projects in your organization might be required to use.

DocumentTemplate Attribute	Description
Default	Optional Boolean. TRUE if the template is the default choice in the Template Type drop-down list box of the New Document Library page.
Description	Optional Text. A description of the template.
DisplayName	Required Text. The display name of the template.
Name	Optional Text. The internal name of the template.
Path	Optional Text. The name of the site template to which the document template belongs.
Type	Required Integer. A unique ID for the template.
XMLForm	Optional Boolean. TRUE if the document template applies to a form library.

Each of the DocumentTemplate elements may contain a DocumentTemplateFiles element which in turn may contain a collection of files that are part of a multi-file document template. Each of these files is contained in a DocumentTemplateFile element that contains a reference to a file that is used within a document template. The following table outlines the attributes of the DocumentTemplateFile element.

DocumentTemplateFile Attribute	Description
Default	Optional Boolean. TRUE to specify that the template file is the default file.
Name	Required Text. The full path to the template file.
TargetName	Required Text. The full path to the target.

The following snippet illustrates how you could include a new document template in your Site Definition. Document template files are stored in subfolders within the [WSS]TEMPLATE1033STSDOCTEMP folder. Storing them using a file structure that includes a locale allows you to have localized templates in different languages if necessary.

<DocumentTemplate
  Path="STS"
  DisplayName="Status Report"
  Type="10001"
  Description="Use this template for a project status report.">
  <DocumentTemplateFiles>
    <DocumentTemplateFile
      Name="doctempwordstatusreport.dotx"
      TargetName="Forms/statusreport.dotx"
      Default="TRUE" />
  </DocumentTemplateFiles>
</DocumentTemplate>

4.1.1.4. Configurations

The Configurations element contains individual Configuration elements that are used to define the Lists, Modules, Site Features and Web Features that are created by default when a site is provisioned using a Site Definition. Each Configuration can also contain an ExecuteUrl element that can be used to specify a URL that is called immediately after a site is provisioned, perhaps to enable some postprocessing. The ExecuteUrl element could be used to simulate a SiteCreated event, which does not currently exist within the WSS v3 object model. Configurations also allow a developer to reuse existing list definitions and modules already defined in the Onet.xml file. The value of the ID attribute for each Configuration element within the Configurations element in the Onet.xml file corresponds to the ID specified in the WebTemp*.xml file containing the configurations for a particular Site Definition. The following table outlines the attributes of the Configuration element.

The Configuration element is used in both the Onet.xml file of a Site Definition and the WebTemp.xml file. In Onet.xml, it is used define configurations as described in the previous paragraph. In WebTemp.xml, it is used to define the specific configurations that are contained within a Site Definition.

Configuration Attribute	Description
AllowGlobalFeatureAssociations	Optional Boolean. Specifies whether global Feature associations are allowed on the template.
CustomMasterUrl	Optional Text. Specifies the URL for a custom .master page to implement in web sites created through the site definition.
Description	Optional Text. Contains the description of the site configuration that appears on the Template Selection page.
DisplayCategory	Optional Text. Specifies a category for the site definition, for example, Collaboration or Meetings.
Hidden	Optional Boolean. Specifies whether the site configuration appears as an option on the Template Selection page.
ID	Required Integer. Specifies a unique ID for the configuration.
ImageUrl	Optional Text. Contains the URL for the preview image displayed on the Template Selection page.
MasterUrl	Optional Text. Specifies the master page to use for web sites created through the site definition.
Name	Optional Text. Contains the name of the configuration.
RootWebOnly	Optional Boolean. TRUE to specify that the site created from the definition exists only as the root web site in a site collection.
SubWebOnly	Optional Boolean. TRUE to specify that the site created from the definition exists only as a subsite within a site collection.
Title	Optional Text. Contains the title of the configuration that is displayed on the Template Selection page.
Type	Optional Text. Identifies the configuration with a specific site definition.
VisibilityFeatureDependency	Optional Text. Used in a WebTemp*.xml file to hide the site definition based on the activation state of the specified Feature. When a site definition contains Features that depend upon another Feature, setting this attribute prevents the site definition from appearing as an option on the New SharePoint Site page if the specified Feature is not installed or activated. This attribute is not supported for Features with the web application scope.

The Configuration element contains the following subelements.

• ExecuteUrl—As mentioned before, this element is used to specify a URL that is called immediately after a site is provisioned, perhaps to enable some postprocessing.

• Lists—This element contains the collection of List instances as well as their default data for a particular configuration.

• Modules—This element contains the collection of Modules for a particular configuration.

• SiteFeatures—This element contains the collection of site collection Features to activate for a particular configuration when a site is provisioned through the Site Definition.

• WebFeatures—This element contains the collection of site Features to activate for a particular configuration when a site is provisioned through the Site Definition.

Perhaps the most useful attributes of the Configuration element is the CustomMasterUrl attribute. Using this attribute allows you to include an additional master page in your site definition that you will be able to use without customizing your pages using SharePoint Designer and consequently storing them in the content database. Essentially, you will be able to provide a custom master page that can be referenced via a simple change in the file system (uncustomized) version of your Site Definition page template file(s). This concept is demonstrated in the walkthrough that begins a little later in this chapter.

As noted in the SDK, WSS v3 activates features specified within the Onet.xml file in the order that they are listed. Consequently, you must specify Features that are depended upon before Features that depend upon them.

4.1.1.5. Modules

The Modules element specifies the modules that are available to all configurations. A module is defined as a file or collection of files as well as a location where the files are installed during site provisioning. Additionally, if one of the files is a Web Part page, the module can specify which Web Parts should be included on the page. The following table outlines the attributes of the Module element.

Module Attribute	Description
IncludeFolders	Optional Text.
List	Optional Integer. Specifies the type of list, which is defined within Onet.xml.
Name	Required Text. Contains the name of the file set.
Path	Optional Text. Contains the URL for the file set. Use only low-order ASCII characters, and no spaces, for Feature folder and file names.
RootWebOnly	Optional Boolean. TRUE if the files specified in the module are installed only in the top-level web site of the site collection.
SetupPath	Optional Text. Specifies the path to a folder in the Windows SharePoint Services setup directory ([WSS]TEMPLATE) that contains a file to include in the module.
Url	Optional Text. Specifies the URL of the folder in which to place the files when a site is instantiated. Use only low-order ASCII characters, and no spaces, for the Feature folder and file names.

Take a quick look at the module included with every Team Site created using the built-in Team Site Site Definition. You can immediately see that the URL for the file (page in this case) is defined as default.aspx. As you move down through the XML code, you can see that this page contains a number of list view Web Parts as well as an image Web Part (contents omitted for space). You will also see an announcements list view Web Part, a calendar list view Web Part, an image Web Part, and a links list view Web Part.

<Module
  Name="Default"
  Url="" Path="">
  <File
    Url="default.aspx"
    NavBarHome="True">
    <View
      List="$Resources:core,lists_Folder;/$Resources:core,announce_Folder;"
      BaseViewID="0"
      WebPartZoneID="Left" />
    <View
      List="$Resources:core,lists_Folder;/$Resources:core,calendar_Folder;"
      BaseViewID="0"
      RecurrenceRowset="TRUE"
      WebPartZoneID="Left"
      WebPartOrder="2" />
    <AllUsersWebPart WebPartZoneID="Right" WebPartOrder="1">
      <![CDATA[<WebPart
        xmlns="http://schemas.microsoft.com/WebPart/v2"
        xmlns:iwp="http://schemas.microsoft.com/WebPart/v2/Image">
        ...
        remainder omitted for space
        ...
      </WebPart>]]>
    </AllUsersWebPart>
    <View
      List="$Resources:core,lists_Folder;/$Resources:core,links_Folder;"
      BaseViewID="0"
      WebPartZoneID="Right"
      WebPartOrder="2" />
    <NavBarPage Name="$Resources:core,nav_Home;" ID="1002" Position="Start" />
    <NavBarPage Name="$Resources:core,nav_Home;" ID="0" Position="Start" />
  </File>
</Module>

A more complete examination of the child elements of the Module element is beyond the scope of this book. The following link tells you everything you need to know: http://msdn2.microsoft.com/en-us/library/ms460356.aspx. Alternatively you could search the SDK for "Module Element (Site)" and be brought to the appropriate location.

4.1.2. Global Site Definition

The Global Site Definition is a new and very special Site Definition found at [WSS]12TEMPLATEGLOBAL. This Site Definition contains the elements required by the framework in order for it to function at the most basic levels, including all of the base types. By isolating as much of the common functionality for each site into the Global Site Definition as possible, custom Site Definitions need only contain the elements that are needed to make the Global Site Definition unique to the business problems that it is being designed to address.

The Global Site Definition is used in the provisioning process of each and every site.

4.1.3. Creating a Custom Site Definition

The following section outlines the steps necessary to create a custom Site Definition by copying one of the existing ones and modifying it to suit your needs. For this exercise you will use the Team Site (sts) Site Definition as a starting point. Keep in mind that best practice dictates that you copy one of the existing Site Definitions that most closely meets your needs and develop from it.

You will be using Visual Studio 2005 to develop your custom Site Definition. By using Visual Studio 2005, you will enjoy the benefits of a full-featured development environment that includes, among other things, color-coding, post-build scripting (to move files around if needed), as well as XML schema validation. Keep in mind that this type of development should only be done in a development environment, never in production. Site Definitions should eventually be deployed using the WSS v3 Solution Framework discussed later in this chapter. The process used here makes it easy to work on Site Definitions, as changes can be seen immediately, since all of the files will be in the correct place on the file system and usable after you build your project.

At this point, your custom Site Definition is ready to be used to provision a site. Creating a site now using your Site Definition would essentially give you a site identical to an out-of-the-box Team Site. Because the purpose of creating a custom Site Definition is to have a custom site, you'll want to make some changes.

Earlier in this chapter you saw that the Project element of the Onet.xml file defined an AlternateCSS attribute and a CustomJSUrl attribute. You are going to use these attributes to allow users of the custom Site Definition to have the ability to override the global styles and/or the default platform behavior (with respect to JavaScript). Now, create both a core.css file and a core.js file, tell your Site Definition where they are, and override a default style.

A common request that comes up with respect to the out-of-the-box look and feel of a SharePoint site is the Quick Navigation menu along the left-hand side of each page (see Figure 4-7). You can manipulate the contents of the Quick Navigation menu by going to Site Settings and clicking on Quick Launch under Look and Feel, but there is no easy way to hide only the header of this menu (the View All Site Content link). One approach is to add a Content Editor Web Part to every page on your site that contains the CSS style necessary to hide this element. This process is very tedious and would need to be done on all pages in the site. Additionally, not all of the pages allow you to add Web Parts. An example of such a page is the viewlsts.aspx page, which lists all of the lists of a specific base type. You can now see that the above process will not work for all of the pages on the site. If you had added the AlternateCSS attribute to your Site Definition before provisioning your site, you would now have the ability to override styles on pages that do not allow you to override them manually, using the above technique, among others. You could also have accomplished this using SharePoint Designer, but that approach would require you to customize each page that you wanted to apply the style to. Yet another way to accomplish this task would have been to remove the appropriate NavBar element from the NavBars section of Onet.xml representing the Quick Launch header.

The following set of steps outline how to add a CSS style to your custom .css file before or after your site has been created in order to inject new look-and-feel styles. This concept can also be applied to the custom JavaScript file.

This technique can be applied to any style. If there is an element on a page whose look you would like to change, simply view the HTML source of the page and search for the style that is applied to that element or its container. Override that style in your custom .css file. Remember, you own both of these custom files.

Remember that most browsers cache pages so that subsequent requests for the same page will appear faster to the end user. Since the above technique modifies an external .css or .js file and not code on the page itself, depending on your browser settings, your changes may not be visible or it may seem like they are not working at all since the link to the external file has not changed, thereby preventing your browser from requesting a newer version of the page. The easiest solution is to manually clear your browser's cache. If that does not "appear" to work, try using a new browser instance and/or resetting IIS.