Creating Content Types

Content Types in SharePoint 2007 is a powerful mechanism to put content into a lifecycle. Mostly it is used to associate metadata with content, which can be useful for searching. Other content type features, such as workflows, information management policies, event handlers and document templates, if leveraged properly can provide robust lifecycle to content within SharePoint. Managing Enterprise Metadata with Content Type is a great whitepaper on content types that describes challenges associated with desigining metadata that is application across enterprise.

Assuming your enterprise has figured out metadata model for enterprise, this post describes various ways of creating content types in SharePoint 2007 along with its pros and cons. 

1. Create using Site Administration User Interface

SharePoint 2007 provides user interface for site administrators to create content types that are scoped at a site collection or a site level.

This is the most restrictive approach, in the sense that content types cannot be leveraged outside the site collection it was created. However, it provides maximum flexibility for the site administrator to change the definition without affecting other site collections. It also does not require developer involvement as there is no custom code required. This approach is particularly suitable for document centers and team sites that are specialized in nature. For example, a document center site collection for storing company policies. Since all policies will be stored in single site collection, there is hardly any need to share the content types outside the document center.

The user interface allows adding site columns, reordering columns, template, versioning, workflows and informationmanagement polcies. It does not allow association of event handlers.

2. Package as SharePoint FEATURE

SharePoint Feature allows content types to be defined declaratively in XML format. Any text editor from Notepad to Visual Studio can be used to write XML, which can be easily packaged into SharePoint Feature and deployed as SharePoint Solution. Content Type Feature is scoped only at site level, therefore, cannot be activated at Farm, web application and sub site level. This is a constraint and needs be considered during design. After a Solution with content type Feature is deployed on  a Farm, the Feature shows up within 'Site Collection Features' list under every site collection. This can Feature can be activated only by a site collection administrator, after which, the content type is provisioned for that site collection. Content type definition can be marked as Sealed to prevent any modification by end user.

Except for Information Management Policies, the XML definition can be used to describe Fields, event handlers and workflows. Each Field in Content Type refers to Site Column and can be used to override display name and mandatory requirement. Event handlers refer to event type and binaries that contain code to execute on particular event. Similarly, workflows refer to workflow definitions that exist at site collection.

The biggest advantage of this approach is having a single content type definition that can be used across site collections. For e.g. if your enterprise wishes to collect specific properties, such as Project Number, Duration, Cost etc., for every project related content, then a Project content type can be defined a SharePoint Feature and made available across SharePoint Farm. Any team site or document center that wishes to store project related content can activate Project content type Feature and  have consistent metadata captured for Project content.

3. Write custom code

Custom code involves writing .NET code using SharePoint Object model to create columns, events, workflows as well as Information management policies. Note that Information Policies are not applicable to content types in WSS. Similar to Feature approach, custom code can provide single content type definition - in form of .NET code - that can be applied across site collections. Code is less desirable for obvious reasons such as testing and maintenance, but provides highest flexibility. Certain operations such as creation of lookup columns and information policies can be achieved only using custom code.

It requires developers to write code and package it as a Feature, where the code runs when the Feature is either Installed or Activated. It is a good practice to remove the content type when the Feature is deactivated or uninstalled. This approach can also be used to provision a content type across site collections within a web application. To achieve this, a developer can create a Feature that is scoped at Web Application and write code in Feature Activated event that create content type in every site collection.

It will be interesting to see how Content Types evolve in SharePoint 2010.