Enhancements in Content Storage

One problem developers had with WSS 2.0 was that several valuable features supported with document libraries were not supported with lists. For example, document libraries supported versioning and events, but lists did not. With WSS 3.0, lists support many of the same features as document libraries including versioning, events, and folders. There are also some new features supported by both lists and document libraries, such as exposing data through automatic RSS feeds.

WSS 3.0 introduces a new column-indexing feature to alleviate some performance problems with document libraries and lists that existed in WSS 2.0. From a list settings page or a document library settings page you can add an index to any column. This does not actually create a physical index in SQL Server. Instead, it creates a table with the integer ID of the list item or document and the value of the indexed column. WSS then uses this table to improve the performance of return data from views, especially when you use a view with a filter based on the indexed column.

Many developers wanted to be able to work with WSS fields at a lower level to obtain more control over field rendering and validation. In response, WSS 3.0 adds new extensible field types. You can create an extensible field type by writing a class in C# or Visual Basic^® that inherits from one of the built-in SharePoint field types such as SPFieldText and SPFieldNumber. An extensible field type can also utilize an ASP.NET user control that contains your favorite Web controls, letting you use the same techniques for control initialization and validation you’ve used in ASP.NET applications.

Another nice innovation in WSS 3.0 is custom site columns. A site column is a reusable definition that can be applied across multiple lists. It defines the name for a column, its underlying field type, and other characteristics such as the default value, formatting, and validation. Once you’ve defined a site column, you can then use it as you define the structure of your user-defined lists. An obvious advantage is that you can update the site column in a single place and have that update affect all the lists where the site column has been used. A site column is defined within the scope of a single site, yet it is visible to all child sites below. You can create a site column that is usable across an entire site collection by defining it inside the top-level site.

Site columns give you the ability to perform field lookups across sites, something you couldn’t accomplish in previous versions of SharePoint without writing custom code. For example, you can create a site column in a top-level site that performs a look up on a list in the same site. Then you can create other lists within child sites that use this site column to perform lookups on the list in the top-level site. Imagine you want to store several different types of documents in the same document library. For example, suppose you need to store customer presentations, proposals, and reports and you want each of these document types to have its own unique set of custom columns and its own unique event handlers. In WSS 2.0, you could only add extra columns and event handlers to the document library itself, which always affects every document in that document library. Furthermore, a document library could have only one associated document template.

WSS 3.0 introduces a powerful new storage mechanism called content types to solve this problem. A content type is a flexible and reusable WSS type that defines the shape and behavior for an item in a list or a document in a document library. For example, you can create a content type for a customer presentation document with a unique set of columns, an event handler, and its own document template. You can create a second content type for a customer proposal document with a different set of columns, a workflow, and a different document template. Then you can create a new document library and configure it to support both of these content types. This is a significant enhancement because it lets you deal with heterogeneous types of content in lists and document libraries.