Content Types – The Soul of a New Paradigm

As you probably know by now, SharePoint 2007 has a new feature called Content Types. Having been asked by more than a few friends and colleagues what they are, or more precisely, what benefits they offer, I decided to share my thoughts. So here goes…

I know it’s an over-simplification, but think about it. List is to content type as data structure is to object.

Remember when objects were all the rage? You know, back when the computing paradigm shifted from “structured” to “object-oriented”? Back then, we used to think about a data type (data structure, really) as a named collection of properties we could treat as a single unit. There were built-in data types with predefined operations we could use to develop applications.

Now, what is a SharePoint List? It is fundamentally a named table with a collection of properties (columns) that we treat as a single unit. There are built-in list types with predefined operations we use to develop SharePoint applications.

Object-orientation introduced the notion that we could model the real world more accurately by binding operations (at least conceptually) to data types and call them “methods”. (I think it’s interesting that whenever the paradigm shifts, we start renaming things.)

So we ended up with a nice programming idiom that allowed us to express things like:

Foo f = new Foo(); f.Name = “John”; f.Print();

The problem with lists in WSS v2 was that the only “operations” allowed were the built-in operations exposed by the SharePoint API. If we wanted to do anything else, we had to implement it ourselves through quite a bit of effort in most cases. If you’re like me, you must have often wondered how great it would be if you could derive your own list types from the built-in lists and extend them with your own custom methods.

So here’s another one to ponder: workflow is to content type as method is to object.

Content types represent an evolution of the SharePoint List to include custom operations, called “workflows”. A content type is basically a named collection of properties (columns) that we treat as a single unit. At the same time, list columns themselves have evolved. Now it’s possible to define Site Columns that can be shared among several lists. Content types can be based on other content types all deriving from a common parent – the System content type. Sound familiar?

So what benefits do content types offer over standard SharePoint Lists?

Consider a typical project proposal. Using content types, we can define a Proposal type and require that whenever a new instance is created, the proposal must be approved by a manager and then distributed to a select list of reviewers who must examine the proposal before it is submitted. All we do is identify the workflows. SharePoint manages the association at the server farm level through an external mapping table.

The beauty is we only have to do this once. From then on, the proposal content type is available throughout the site and can be attached to lists and document libraries as often as we like. We can go on to derive new, more specialized content types from it and automatically inherit all of the meta-data as well as the workflow associations.

Another benefit is that you can define search queries based on content types. So, for example, you can define search conditions such as ‘where content type = proposal’. If you change a content type, you can automatically push those changes out to all derived content types. Similarly, if you change a site column definition, that change is automatically reflected in all content types that reference the column.

Yet another benefit is that you can associate multiple content types with the same list. So, for example, you could create a single document library that contains many different kinds of proposals, all based on different content types with different workflow associations and meta-data.

To me, it’s all about having the tools to describe operations that occur at the enterprise level and depend on humans to get work done. Bill Gates once referred to it as the “digital nervous system” of an organization. With Content Types and Workflow, we now have a programming idiom that allows us to describe the path that information takes as it moves through the enterprise. We have the ability to encapsulate business processes and bind them to a hierarchy of reusable data types that are bound to the content itself.

For more information about content types, check out the SDK. Also, Andrew May has created some nice diagrams of content types and related technologies.

<

p class=”zoundry_bw_tags”>Technorati : Content Type, MOSS, SharePoint, Workflow
Del.icio.us : Content Type, MOSS, SharePoint, Workflow