Version 3 of the SharePoint platform introduced the concept of features. Features are a collection of elements that modify, override, and extend the platform. These elements can contain infrastructure components (definitions, templates, and so on) and can create instances of content items (lists, pages, and so on). The feature framework is very flexible: The elements in a feature can be applied to a scope (valid scopes are the entire farm, a Web application, a site collection, and a site), and developers can run custom code when a feature is activated. Every component created by a developer should be packaged into a feature. The feature is then installed and activated in the appropriate scope by the owner of the target SharePoint object.
The feature framework provides over a dozen different element types. This section discusses those types, providing an example of where each is used.
Custom action elements are used to add, or hide, links and options to the user interface of SharePoint sites. The most frequent use of custom action elements is in the creation of custom SharePoint-based applications and the restriction of SharePoint management activities to a smaller set of site members. Figure 12-6 shows an example of a custom action.
A SharePoint-based application will usually contain custom pages. Rather than relying on users to remember the URL of these pages or using their browser Favorites, developers can provide a link to the pages within the SharePoint interface. Custom action elements allow for adding a link to many different areas in the interface. Links can be added to the Central Administration pages, to the Site Settings page (for the top-level site or all sites), to the Site Actions menu, to the toolbar of a list, and to the context menu of a list item. These links function just like any other SharePoint-provided link. They can be security trimmed to show only if the current user has the appropriate permissions, and they will inherit the look and feel of the site.
Custom action elements can be targeted to users with specific permissions (called rights) to the applicable object. This targeting is accomplished via two different attributes: Require-SiteAdministrator and Rights. The RequireSiteAdministrator attribute is a simple true/false value. The Rights attribute is used to provide a finer level of granularity to the action. The list of valid rights can be found in the Windows SharePoint Services SDK under SPBasePermissions.
The HideCustomAction element will remove the specified link from the display. This element can be used to remove links, even SharePoint-provided links, from the display. However, the HideCustomAction element cannot be targeted to specific users, so it should be used in conjunction with a custom action element that is targeted to the appropriate users. Otherwise, the functionality will not be visible to anyone, which may cause difficulties in the future when the functionality is necessary.
The Control element, also called DelegateControl, provides for changing the display of specific items in the SharePoint interface. Control elements are loaded inside a tag named DelegateControl that is included in many of the out-of-the box administrative pages.
Note
The display of Web part pages can be changed by adding or removing Web parts, so the DelegateControl is not often used on them. However, the search box at the top of Web part pages and list forms is inside a DelegateControl. This allows customization of the search interface and search parameters.
Module Element
The Module element is used to create a page in a SharePoint site when the feature is activated. The page can be part of a document library or outside of a library. Any type of page supported by the SharePoint platform can be created, including Web part pages, master pages, and content pages. If the page being created is a Web part page, the Module element provides for the inclusion of Web parts, including views of lists, on the page as it is created.
When a file is created using the Module element, it will appear in the list of files in the library or in the site when viewed in SharePoint Designer 2007. However, the file is not initially copied into the content database. In order to improve performance, SharePoint Products and Technologies makes extensive use of caching on the WFE Servers. This minimizes the amount of data that must be retrieved from the database server. When a feature containing a Module element is activated, the content database is updated with an entry for the file that refers to the location on the server’s file system, i.e. 12 FEATURE[Feature name]. If the file is later customized via SharePoint Designer 2007, the differences between the original and the customized version (called the delta) are stored in the database. When the page is rendered, SharePoint Server 2007 starts with the cached version from the file system and then applies the delta from the database.
To make these pages visible in the browser interface, the feature can contain custom action elements as discussed earlier. Also, the Module element can specify NavBar elements that specify the name and location of the new page in the site’s navigation. For anything other than a non-trivial SharePoint Products and Technologies implementation, it is a best practice to limit customizations that result in copies being made in the content database. It is preferable to manage resources from the file system to the greatest extent possible.
The native list templates provided by Microsoft are designed to communicate unstructured information. Announcements, events, and tasks contain information that is horizontal in nature. That is, the information applies to a wide variety of companies, departments, and groups regardless of the business activity that the group performs. These groups will likely create more specific lists that contain data that is much more structured. When these custom lists must be used in different sites, the Field element is used to define the individual columns, called site columns, and the ContentType element is used to define a collection of related columns. Site columns and content types created via the feature framework are included in the Galleries section of the Site Settings page.
Site columns and content types can be created via the browser instead of the feature framework. However, these items cannot be copied to other locations in the farm. Even if the exact changes are made to two different lists, they are not considered to be the same because they will have two different identifiers assigned by the SharePoint Products and Technologies platform. To ensure that the items have the same identifier, they must be created via the feature framework. This identifier discrepancy is noticed most often in the publishing infrastructure.
The ListTemplate element defines the properties of a list. The ListInstance element actually creates a list based on the specified template. The combination of these elements is very powerful for application developers.
Most applications require storage, and the SharePoint Products and Technologies platform easily provides storage of any structure. In addition, the SharePoint Products and Technologies list forms will dynamically create forms for creating, viewing, and editing items in a list. Including a ListTemplate element and a ListInstance element in the application’s feature set will leverage the platform with minimal effort. The ListInstance element can also include data with which to initialize the list.
The FeatureSiteTemplateAssociate element will associate a feature with a site template. This association is also known as stapling. When a site is provisioned using the site template, all stapled features are automatically activated on that site. This element allows developers to extend a native site template to include additional functionality without changing the files provided by Microsoft.
Note
Changing the provided files is not supported by Microsoft and may be overwritten in future releases of the product to include service packs.
There is a bit of overlap between stapling and site definitions. Feature stapling is the preferred approach due to its upgradability. Once a site has been provisioned based on a site definition, changing the definition is not supported. In addition, any pages that have been customized using SharePoint Designer 2007 will not reflect any changes to the definition files. However, changes to components in a feature can be applied to existing sites using a feature with the incremental changes.
The SharePoint platform includes support for Workflow Foundation workflows. These workflows can be created using SharePoint Designer as well as Visual Studio. Workflows created in SharePoint Designer are automatically bound to a specific list in a specific site, and do not use the feature framework. The Workflow element applies only to workflows created using Visual Studio.
The Workflow element is used to describe the components of the workflow. This includes its identifier as well as the forms used and the assembly to call at each step. Workflows that capture or generate data will likely contain Field and Content Type elements that specify the structure of the data.
The remaining elements are used to instruct the SharePoint platform to execute custom code. These are the Receiver and DocumentConverter elements. The Receiver element is used to specify the code to execute in response to list events. The listing of list events can be found in the Windows SharePoint Services SDK under SPEventReceiverType. The DocumentConverter element is used to specify the code that is used to convert documents from one format to another. The DocumentConverter element works in conjunction with the Document Converter Process.
The feature framework provides provisioning callouts that work similarly to the executable elements described previously. By specifying a class and its strongly named assembly, custom code can be executed when features are installed, activated, deactivated, and uninstalled. It is important to note that, while these are often called events, they are in fact code callouts. In the .NET framework, events can be cancelled by returning a value to class that raised the event. The feature callouts cannot be canceled.
Feature callouts should be used to set initiation data or configuration settings that cannot be performed using feature elements. You might require a feature-activated callout if you are creating a SPWebConfigModification class to update the Web.config file of a Web application, populating a list with dynamic values (static values can be specified in a ListInstance element), or creating a timer job to perform tasks at a scheduled interval.
Any modifications made during feature installation/activation must be removed during feature deactivation/uninstallation. It is common for features to be deactivated and reactivated. This cycling of feature status should be handled correctly and tested thoroughly.
Feature callouts must be carefully written. Any unhandled exceptions will leave the feature in an invalid state. The callout code is run without a user interface, so the code should output information to the trace logs. Information about the trace logs can be found in the Windows SharePoint Services SDK under Trace Logs.