Features in wss3.0 - Part 1

Why Features came into existence?

When a site was created in wssv2, it was not easy to add new functionality to the site at the later date without writing some custom code to implement the changes. In addition, when some sort of functionality was reused across multiple site definitions or site template in wssv2, the functionality was literally copied to each site definition or template.Another benefit of using Features is in the use of site definition (ONET.xml) files. ONET.xml files provide Windows SharePoint Services with information about the navigation, lists, and document libraries that users can create. In the previous version of SharePoint, ONET.xml files have a tendency to get very large. With the advent of Features, the ONET.xml file shrinks because Features can now contain the information that was previously defined in the ONET.xml file.

Onet.xml
When you install Windows SharePoint Services 3.0, six Onet.xml files are placed within the setup directory, one in \Program Files\Common Files\Microsoft Shared\Web Server Extensions \12\TEMPLATE\GLOBAL\XML that applies globally to the deployment, and five in different folders within ...\TEMPLATE\SiteTemplates that apply to each of the five site definitions that ship with Windows SharePoint Services 3.0. They are Blog sites, the central administration site, Wiki sites, Meeting Workspace sites, and team SharePoint sites. Only the last two of these families contain more than one site definition configuration in Windows SharePoint Services 3.0. The global Onet.xml file defines list templates for hidden lists, list base types, a default definition configuration, and modules that apply globally to the deployment. The five Onet.xml files in the \SiteTemplates directory define navigational areas, list templates, document templates, configurations, modules, components, and server e-mail footer sections used in the five site definitions.

Working with Features

Features reduce the complexity involved in making simple site customizations, and are robust when upgrades are applied to a deployment. Features eliminate the need to copy large chunks of code to change simple functionality. Features thus reduce versioning and inconsistency issues that may arise among front-end Web servers. Features make it easier to activate or deactivate functionality in the course of a deployment, and administrators can easily transform the template or definition of a site by simply toggling a particular Feature on or off in the user interface.
Exploring the Components of a FeatureFeatures are typically stored on the SharePoint server at C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES. Each Feature has its own sub-directory that resides in this directory. Inside each Feature's sub-directory, you will find, as a minimum, a header file named feature.xml. The feature.xml file points to a manifest file that tells SharePoint where to find the code and XML that defines the Feature. The feature.xml file contains the Feature element that specifies the location of assemblies, files, dependencies, or properties that support the Feature. Optionally, the Feature element may point to an XML file that contains an Element element which defines the components and types that make up the Feature.The following are samples of the components that comprise a Feature.The Feature.xml File
The feature.xml file defines the metadata associated with a Feature.

< Feature Id="00BFEA71-E717-4E80-AA19-D0CBE412FFA6"
Title="Hello World Feature"
Description="$Resources: core,documentlibraryDesc;"
Version="1.0.0.0" Scope="Web" Hidden="FALSE"
DefaultResourceFile="documentLibrary"
ImageUrl="menuprofile.gif >
< elementmanifests >
<elementmanifest location="elements.xml" >
</elementmanifests >
</feature >

The following metadata is contained in the element in this XML file.
• ID: The GUID that uniquely identifies the Feature. This value must be unique across the server farm.
• Title: The name of the Feature. In an actual scenario, you will see the name of the Feature displayed on the Site Features web page inside the Site Settings section for a given SharePoint site.
• Description: The description of the Feature. Notice that in this sample, the description is retrieved from a resource file (a file with a .resx extension) instead of hard-coded in the file. The strings are stored as key/value pairs within the resource file. The following is a segment from a resource file named documentLibrary.resx that provides the description of the sample Feature.
• Version: The version of the Feature. This value can be incremented for successive versions of the Feature.
• Scope: Web or Site are the typical values. The scope defines the context in which the Feature can be activated or deactivated. Setting the scope equal to Web means that the Feature can be activated or deactivated within the context of the site. A setting of Site means that the Feature can be activated or deactivated within the scope of a site collection. The scope is set to the site collection displayed to the administrator in the Site Collection Features page. There are also WebApplication and Farm values.
• Hidden: TRUE or FALSE are allowable values here. This setting specifies if the Feature is visible in the list of Features on the Site Features web page. Setting the attribute to TRUE makes the Feature visible to users who want to activate it. Hidden Features must be activated either from the command line, in custom code, or through the dependency of another Feature.
• DefaultResourceFile: Specifies the central location for settings and other items that may change frequently.
• ImageUrl: Points to an image file that will be displayed next to the Feature in the user interface. • element: The container element for elements.
• element: Contains the location of the manifest file that contains the different elements that this Feature implements. The path to sub-directories and files is a relative path.

The Element.xml File

The Element.xml manifest file contains details of the different components or actions that make up a Feature.


< Elements xmlns="http://schemas.microsoft.com/sharepoint/" >
< Field ID="{0B9E3314-3F9F-2aa8-4BCD-7CB89A6FB32D}"
Name="ProductName"
SourceID=http://schemas.microsoft.com/sharepoint/v3 StaticName="ProductName"
Group="ProductColumns"
DisplayName="Product Name" Type="Text" >
< /field >
< /elements >
Here, the manifest file defines a field that might be used in a list column.