Features are the preferred packaging mechanism for SharePoint
Features can include activation dependencies . When WSS activates a feature that defines activation dependencies, it automatically activates any dependent feature that has already been activated. The TeamCollab feature that ships as a built-in feature with WSS provides a good example. The TeamCollab feature in and of itself provides no implementation. However, it defines activation dependencies on 19 other built-in features that define the collaboration lists and libraries in the Team Site.
Activating the TeamCollab feature forces the activation of these 19 other features that make all of the collaboration list types available such as Announcements, Contacts, Tasks, Events, and Document Libraries. As you can see, feature activation dependencies can be used to aggregate many features together into a common feature set that can then be activated and deactivated through a single high-level feature. Note that the STS site definition contains a Web feature reference to the TeamCollab feature so that all collaboration features are available within any new Team Site, Blank Site, or Document Workspace.
To
<?xml version="1.0" encoding="utf-8"?> <Feature Id="" Title=" Chapter 8: Vendor List Instance" Description="Demo from Inside Windows SharePoint Services" Version="1.0.0.0" Hidden="false" Scope="Web" xmlns="http://schemas.microsoft.com/sharepoint/"> <ActivationDependencies> <!-- LitwareTypes Feature --> <ActivationDependency FeatureId=""/> </ActivationDependencies> <ElementManifests> <ElementManifest Location="VendorListInstance.xml" /> </ElementManifests> </Feature>
We create an ActivationDependencies node within the feature to define elements that will be enabled when this feature is added. Next, we move the ListInstance node from the VendorList.xml file to a new VendorListInstance.xml file within the VendorListInstance feature folder. VendorListInstance.xml should look like the following code:
<Elements xmlns="http://schemas.microsoft.com/sharepoint/"> <ListInstance TemplateType="10001" Id="Vendors" Title="Vendors" Url="Vendors" Description="Litware Vendors" OnQuickLaunch="True" > <Data> <Rows> <Row> <Field Name="Title">Acme Corp, Inc</Field> <Field Name="FullName">Bob Jones</Field> <Field Name="WorkPhone">(813)345-5432</Field> <Field Name="Industry">High Tech</Field> <Field Name="CompanySize">101-1000</Field> <FieldName ="ActivityNotes">They got the best widgets</Field> </Row> <!-- (Additional rows omitted for clarity) --> </Rows> </Data> </ListInstance> </Elements>
We have created a feature that provisions a new list instance on activation. However, the feature is designed to force the activation of the dependent feature that defines the underlying list type when this is necessary.
A feature can also be used to attach one or more other features to a site definition through a technique known as feature stapling . For example, instead of creating a custom site definition, you can elect to create a custom feature to extend one of the built-in WSS site templates, such as Team Site or Blank Site, by automatically associating it with the Litware Types feature. You can extend a site template in this fashion by using a feature site template association.
{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}
To add the Litware Types feature to Team Site and Blank Site, you can simply create a new feature that
To use feature stapling, create a new feature to be used to associate one or more other features with one or more site templates. In the code samples for this chapter, we defined the new Feature folder named LitwareTypesDeploymentFeature in the Litware Types project in use since Chapter 6. This feature will only contain two files, the feature.xml file and the elements.xml file. Within the Elements node of Elements.xml, we created a FeatureSiteTemplateAssociation node for every site template to which we want to staple our feature. In this case, we want to staple the Litware Types feature to the Team Site (STS#0) and Blank Site (STS#1).
<Elements xmlns="http://schemas.microsoft.com/sharepoint/"> <FeatureSiteTemplateAssociation Id="" TemplateName="STS#0" /> <FeatureSiteTemplateAssociation Id="" TemplateName="STS#1" /> </Elements>
A feature created to perform feature stapling can be defined to be activated at any of the four supported activation scopes, including the scopes of site, site collection, Web application, and farm. For example, if you define a stapling feature at Web application scope, it provides a quick and easy way to activate the features being stapled within every Team Site and Blank Site in the target Web application. In the sample code for this chapter, we designed the stapling feature at farm scope. Once this feature is activated, it makes the Litware Types feature active within every Team Site and Blank Site in the farm.
Going one step further, we could associate the Litware Types feature with Global site definition configurations, which makes it available to all sites as opposed to only sites created from a specific configuration. The following elements manifest would associate the feature with the Global site definition configuration:
<Elements xmlns="http://schemas.microsoft.com/sharepoint/"> <FeatureSiteTemplateAssociation Id="" TemplateName="GLOBAL#0" /> </Elements>
Attaching the Litware Types feature to the Global site definition configuration makes it globally active in all sites throughout the current WSS farm, including the Central Administration sites. This technique is powerful because it provides an approach to using feature stapling to make custom list types available to every site within a farm. You can also use it to import Web Part description files into the Web Part gallery of every site collection on a farm-wide basis.
Keep in mind that feature stapling can also be used to associate features that contain event handlers. For example, imagine that you want to run a piece of custom code