So far in this chapter, you’ve seen how we can package our customizations using features and solutions. By using these methods, we can activate and deactivate particular features to achieve our desired level of functionality. This process works well if we’re adding functionality to an existing site, but what happens if we want to create a new site that uses functionality that’s encapsulated in a number of features? As we did in an earlier example, we could start out with a blank site and enable the appropriate features. However, SharePoint provides a better way to achieve this result. We can create a custom site definition.
To understand how a custom site definition fits into the overall picture, select New Site from the Site Actions menu on any SharePoint site. Each of the items listed in the Create dialog is an example of a site definition. Basically, a site definition is a template that can be used to create new sites. By creating a custom site definition, we can specify how a new site is provisioned, including which features should be activated and which lists and libraries should be created by default.
NOTE:Regarding site definitions versus site templates, from SharePoint Designer, we can save a site as a site template. When using this function, we’re actually creating a WSP package that contains a list of customizations to whatever site definition the site was created from. This type of site template can then be applied to other sites that are derived from the same site definition. This functionality differs from that of creating a custom site definition because site definitions can be used only when creating new sites.
Confusingly, site definitions as stored on each front-end server in the %SPROOT% TEMPLATE Site Templates folder. In a similar manner to features, each site definition has its own folder. The site definition configuration is stored in a file named onet.xml within the XML folder.
Site definitions have been part of SharePoint since day 1, whereas the feature framework was introduced in Windows SharePoint Services 3.0 to provide a higher degree of flexibility. As a result of this, site definitions come with some serious baggage and can be pretty complex. The recommended approach with SharePoint 2010 is to factor as much configuration into features as possible. This helps to keep site definition files maintainable while still allowing a high degree of flexibility.
TIP:When creating site definitions, bear in mind that future service packs for SharePoint may overwrite out-of-the-box files. Always create a separate folder for any customized site definitions. As you’ll see when using Visual Studio, this approach is adopted automatically.
Creating Site Definitions Using Visual Studio
Let’s look at how we can create a new site definition using Visual Studio.
A new project is added containing the following files:
If we examine the onet.xml file that’s been added to our project automatically, we’ll find the following XML:
NOTE :Site definitions can get pretty complex. A full discussion of each of the elements in the onet.xml file and how each can be used is beyond the scope of this.
The most important element in the onet.xml file is the Configuration element. Each file can contain more than one Configuration element, and each element must have a unique ID. The Configuration element effectively defines a distinct site definition. Our file has a single site definition named ChapterDemoSite, which refers to a module named DefaultBlank.
Our onet.xml file also contains a Modules section that is outside the Configurations section. These modules can be shared between all configurations in the file. Modules are used to provision files to a SharePoint site and can also be added as feature elements by adding a Module item to a project. In our sample, the default.aspx file is being provisioned to the root of the new site.
Site Features/Web Features
As mentioned, with SharePoint 2010, the recommended approach to creating site definitions is to use features as much as possible. We can specify which features are automatically activated when a site is created by adding Feature nodes to the SiteFeatures and WebFeatures elements. These elements represent features that should be activated at the Site collection level and features that should be activated at the site level.
Add the following XML to the WebFeatures node:
Features are referenced using their unique identifier. To find the identifier for a particular feature, you can use a few techniques. If the feature is a custom feature, the identifier can be found in the Feature ID property that can be seen in the Properties pane in the Feature Designer. If the feature is an out-of-the-box or third-party feature that’s already installed on a server, the following PowerShell command can provide a list:
Our site definition will now automatically activate our two features when a new site is created. Deploy the solution by choosing Build | Deploy in Visual Studio.
After the deployment process has completed, navigate to the sample site that we created earlier, and then select New Site from the Site Actions menu. In the Create dialog, select Chapter19DemoSite from the SharePoint Customizations category. Name the new site Demo and then click Create. A new site will be created, as shown, that contains the lists defined by our features:
Share Point 2010 Related Interview Questions
|Web Services Interview Questions||XML Interview Questions|
|Share Point 2010 Interview Questions||ASP.NET Interview Questions|
|Share Point Administration Interview Questions||BizTalk Admin Interview Questions|
|Microsoft Office SharePoint Server (MOSS) Interview Questions||Biztalk Server Interview Questions|
|Asp Dot Net Mvc 4 Interview Questions||Biztalk Esb Toolkit Interview Questions|
|InfoPath Interview Questions|
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.