Defining Content Types
In SharePoint 2003, SPS and WSS, you were limited to a single set of columns and metadata tags per list or document library. This meant that all of the items that were in those lists and libraries were tied to that schema. To solve this problem, SharePoint 2007 introduces the content types.
Content types are a way to manage the metadata and behaviors of a document, list item, or folder in a centralized, reusable way. At their core, content types contain a set of properties, a document template, a set of policies, and any applicable workflows. Site content types created on the site can be reused in multiple lists, and they are visible in that site and all child sites. Content types can store custom XML data, allowing for the implementation of custom solutions. MOSS 2007 doesn’t care what file format or type of media you are working with. In other words, Office files, PDFs, TIFFs, e-mail, videos, and physical records can all be classified using content types.
Site columns work nicely with content types as a way to standardize the metadata that is captured when a particular content type is selected. Both site columns and content types are created at the site level and then copied locally as customizable instances or list content types and list Columns when you add them to a list. When a site column is added to a content type, the content type actually references that site column definition.
Content types can include the following:
Document type: Word, PowerPoint, Excel, InfoPath, TIFF, PDF, and so on
Metadata: Project Type, Project Status, Date Created
Workflow assigned to it: If project amount > $5,000 send on to Workflow1
File Plan: Delete after five years
Event handlers: Convert a document to PDF
XML information: Use in a custom solution
You can create content types using three different methods:
Through the Windows SharePoint Services user interface
Through the Windows SharePoint Services object model
By deploying a feature that installs the content type based on an XML definition file
Cross-Ref
For more information about using Features, see Chapter 9.
A content type can be associated with a list or library. When configured, the content types show up under the New command in that list or library so that users can create new items with those properties.
Lists and document libraries often contain more than one content type. When they do contain more than one, the New command allows them to create new items of all associated content types. Additionally, the columns associated with those content types all appear.
Content types are not tied to a particular list or library, which means that they can be used on multiple sites. Administrators are able to manage the templates, properties, and workflows of a content type from one location, while that information is updated in the sites downstream.
Content type hierarchy
Content types are organized in a parent/child hierarchical relationship. There are site content types and list content types. It is useful to think of site content types as templates and list content types as instances of those templates. An advantage of site content types is that they are not bound to a particular list. The site level where the site content type is created determines the scope of that content type.
When a site content type is assigned to a list, a copy of that content type is copied locally onto the list. Once copied locally, it can be modified so that it is different from its site content type parent. A content type can be created directly on a list, but it would not be available to other sites or lists.
Site content types can be based on other site content types. Take the out-of-the-box content types that come with WSS such as Folder, Document, and Task as an example. You can create site or list content types based on any of these types. All content types derive from the top of the hierarchy type, which is System. Changes made to a site content type can be pushed down to the child types, both site and list. This is a one way push from parent to child.
Note
When multiple content types are allowed on a list/document library, you will be forced to select a content type every time you place a new document in the library and to configure policies explicitly for each content type, rather than on the list/library.
Creating content types from other content types
Content types can be created based on other content types. Your existing library of content types is like a set of templates for you to choose from. You can save time by building your custom types hierarchically. In other words, build base types that can be the foundation for other types by incorporating core company fields and other properties.
Site content types are available for their child sites and also for sites lower in the hierarchy. The content type hierarchy included in WSS 2007 maps to the available types of lists that can be created. Examples of base content types are Issue, Contact, Announcement, Document, and so on. Each time a list is created, WSS creates a list content type based on the base site Type. In other words, if you create an Event list, the Event content type is copied locally to the list.
Property integration with Office 2007
Office 2007 applications all have a new feature called the document information panel. The panel displays an InfoPath-editable form that is used to enter and display properties that are on the server. When configuring a content type, you can use InfoPath 2007 to generate a default property form that is based on the properties of your content type. Your form will include the controls and layout and you can then customize it as you would any other InfoPath form, in addition to using it in the document information panel.
Data collection in Office overall has been enhanced through this integration with Infopath. Electronic forms can be presented in the Infopath client or in a Web browser as well as embedded in Word and Excel documents as well as being embedded in Outlook 2007 e-mail messages. These options provide new ways to collect data in more intuitive ways that are in the context of what the end user is doing.
Using site columns
Site columns are a huge productivity gain for SharePoint site administrators and designers. In SharePoint 2003, adding custom columns to a list and library was a very useful feature. It allowed the quick creation of useful metatags, and then views were created to show just the content that matched a particular context, page, or site. You would quickly find that you were creating the same type of metadata and columns over and over again—for example, a column called Document status that showed the following:
Draft
In Review
Approved
Archive
Not only would you find yourself creating the same columns over and over again, but you would also have to try to remember every place that used the column to make changes and updates. This repetitive work is history with site columns in SharePoint 2007.
Site columns are similar to content types in that they keep metadata in sites and lists consistent, and they can be used in multiple lists and sites. Site columns are SharePoint list fields and are defined at the site level. Again, similar to content types, you will want to pay attention to your site hierarchy. Sites columns that you would like to have available to all lists and sites should be created at the topmost site in your portal.
One example of a useful site column would be a Company Name lookup column. There are many sites and documents where you may want to track the company name associated with the documents and activities. Creating a Company Name list and then a site column that does a lookup on the list will provide access to it on all child sites.
Site columns are defined by properties such as name and data type. The name of your site column must be unique within the site structure or scope where it is defined. When added to a list or content type, you can specify site column properties such as required, read only, and hidden.
Cross-Ref
Site Columns can also be deployed as Features. For more information about Features see Chapter 9.