Enable Document Versioning
Now that we have a document library for change requests, we need to enable version control so we can track changes made to the document. This can be accomplished by using VersioningEnabled attributes of the List element such as:

<List xmlns:ows="Microsoft SharePoint" Name="Change Requests" Title="Change Requests"
VersioningEnabled="TRUE" Direction="0" Url="Change Requests" BaseType="1" >

ExecuteUrl
Although CAML is a powerful tool for customizing your site definition, you will more than likely run into issues that can not be solved while using it. A case in point is the configuration of content approval for a list. If you need to turn content approval on for a specified list within your site definition there is currently no way to do this using CAML. However, there is a project attribute, ExecuteUrl, that can be used to execute a page from a specified Url whenever a site is created. Using this attribute allows you to create a code module that you can use to work directly against the WSS object model. This is a great way for dealing with those requirements that don't seem to have an eloquent solution from within CAML. The one downside to ExecuteUrl is that it only works from the WSS create wizard, so it won't work when creating Area sites from the portal, nor will it work from custom code where SelfServiceCreate is being invoked. If you decide to use a build script for deleting/creating sites during development, remember that the ExecuteUrl will not be invoked.

<Project Title="Project Management Site" ListDir="Lists" xmlns:ows="Microsoft SharePoint"
ExecuteUrl="_layouts/ConfigureProjectManagement.aspx"

CustomJSUrl
SharePoint uses quite a few JavaScript functions for providing menu options and other client-side functionality. You may find a need to disable one or more menu items from one of the context menus within a SharePoint list or document library. These lists are generated by the ows.js file; this file should not be edited. SharePoint provides a great way to override functions in the ows.js file by allowing for site definitions to invoke a custom JavaScript file. The CustomJSUrl property is specified within the project element of the ONET.XML file for your site definition. SharePoint will include the url for the javascript file after the inclusion for the ows.js file, which allows you to override functions and/or create new functions. For this example we will use a file named pm-ows.js that has been placed in the layouts virtual directory.

<Project Title="Project Management Site" ListDir="Lists" xmlns:ows="Microsoft SharePoint"
CustomJSUrl="/_layouts/pm-ows.js">

You should always provide a value for the CustomJSUrl property even if you don't currently have a need to override anything in the ows.js file. Doing so will allow you to easily incorporate custom functionality after sites have been created with your new site definition.

Deployment
To deploy your site definition, all you have to do is copy the site definition folder and the corresponding WEBTEMP file to the target server (assuming that you haven't created any custom Web parts) and then restart IIS.

Conclusion
Custom site definitions give you quite a bit of flexibility for creating sites that meet the specific needs of your domain by allowing you to customize and extend SharePoint. When your application requires that custom features be developed, tested, and then applied in a consistent and repeatable manner, you should consider this approach. By following the best practices described in this article you can greatly reduce the complexity of the development process.

Resources

• Figure 1
• Figure 2
• Source Code