This post discusses lists and content types in SharePoint. It’s an overview of the concepts from a developer’s perspective.
Before getting into content types, it’s important to do a brief review of Lists. Central to SharePoint is the concept of a list, which is often compared to a database table. If you spend any amount of time with lists you’ll quickly see the similarities. Like database tables, lists have columns and rows. You can query them, modify them, sort them and even index them. And both lists and database tables also have a variety of column types for things like text, numbers, dates... Conceptually, they’re equals.
So why use lists in SharePoint? Well, there are a number of features above and beyond what you can do with simple database tables. Here are some of the main benefits:
- User Interface: A SharePoint list provides not only the storage, but the user interface for working with the data.
- Item Security: Lists support row-level security and security trimming.
- Versioning: You can store multiple versions of data.
- Ease of Use: Lists can easily be modified from within the browser. End users can make these changes without a developer.
- Content Types: Lists support content types.
- There’s more, but I don’t have all day :)
User Interface
When you create a list in SharePoint, you get (for free) the user interface for working with the data in the list. You get a new form, edit form, display form and a variety of views to display the data in a listing format. As you add new columns the user interface changes and users can easily enter that information. Compare this to a database table. If you’re an end-user, you need to call a developer to modify the forms as fields change in the database. A real pain and definitely not worth anyone’s time, in my opinion.
Item Security
You can lock down one row of data in a SharePoint list. This not only prevents access to that one item, but it also prevents unauthorized users from actually seeing data in the list. Even when you query the object model and retrieve items (rows) from a list, your results have unauthorized records trimmed out automatically. That’s really cool. Try doing that in a database. It’s a lot more work.
Versioning
When you modify data in a SharePoint list, you have the option to enable versioning. This will keep track of all changes for all columns in the list. This feature also allows you to revert back to previous versions. This is difficult to achieve in a database table solution.
Ease of Use
End users no longer have to bother the developer when they want to create a list to store something. On their own, and with proper permissions, users can create and modify new lists. Since all the forms are already done and up to date, users can essentially build a “web application” that has the functionality that used to take weeks to do in plain-old ASP.NET. What?!!! You mean that I can no longer charge my clients to build tables and the simple CRUD forms used to input/edit data? That’s right. All the out-of-the-box capabilities of SharePoint has essentially raised the bar regarding client expectations. Clients expect it done now and can they actually do it themselves. However ... do not despair. There’s still plenty of software development to be done for your SharePoint users: workflows, web parts, custom jobs, custom forms... Clients are never satisfied for long and, for a developer, this is a good thing.
Content Types
Let’s spend the remainder of this post on Content Types. A content type is essentially a set of columns that can be used over and over in multiple lists.
Before we get too deep, you need to understand that columns can live on their own. In a SharePoint site, there’s a special list of “Site Columns” that are already created and can be used in multiple lists. For instance, there are standard columns like Author, Address, Spouse, and many more. These are listed in the Site Column Gallery. This is found on the Site Settings screen.
And when you look at the Site Column Gallery, you’ll see a list of columns that Microsoft provides. You can add your own, too.
So Site Columns live in the Site Column Gallery. They have all the settings required for each column. For choices, these are things like the actual choices that need to be selected. For others, it might be whether or not they’re required.
You can add one or more columns to a list when you go into the list settings screen of the list. Here’s a simple Projects list where we want to add some site columns. As you can see, it can be a real time-saver compared to creating new columns on the list each time.
Next choose to add from existing site columns.
Then choose some columns to add. Pretty easy.
So now we have a list with new columns no big deal. But where do Content types come into this. Well, just as we can add columns to a list, we can add columns to a Content Type. Let’s create a Project content type and show how we can use that on two different lists (one for internal projects and one for external projects).
There’s another gallery that we need to introduce. This is the Content Type Gallery. Look under Site Settings and you’ll see this.
From here, we can see all of the built-in content types. Open the Contacts content type and look around.
Notice how the Columns appear here just like they did in our list settings screen. Although the content type doesn’t really store any data, it does define the structure of the data. Let’s create a new content type for our projects. Go back to the Content Type Gallery and click Create.
Next, give the content type a title and choose “Item” as the parent content type. This is found under the “List Content Types” category. I’ll talk more about the parent content type shortly.
Once you’ve done this, you’ll be sent to the content type settings screen for your new content type. From here, you can add new columns as necessary. Notice that you already have a Title column. This is because we chose the Item content type as it’s parent. Item is the top-most content type for all items in SharePoint. Every content type you create must use Item as a parent or some child of Item. This is a really powerful concept that essentially lets you “inherit” the columns from a parent type. It’s really just that simple. We inherit from Item and we automatically get a Title fields. If we inherited from Contact, we would get all the fields of Contact. Let’s add some of our own fields for our project structure.
Note that you can create new site columns on the fly, but we’ll just choose from the existing site columns. It’s quicker. Add some columns that make sense for projects.
Now, let’s create a couple of custom lists: Internal Projects and Client Projects. From the Create page, choose Custom List.
So now, we have three lists. The one I originally started with where I added my own columns and the two we just created. So we have two distinct lists to contain our internal and client projects now. Let’s enable content types for each and then choose our “Project” content type. Here are the steps for the Internal Projects list. First, go to the settings for the list and choose Advanced Settings:
Next, choose to enable content types.
This gives us the ability to add new content types. It also shows a new section in the list settings page that displays the content types that are in play.
Notice the new section. Also notice that one content type is already in play. Content types are always in play in SharePoint lists and document libraries. Allowing management of content types simply let’s us see and work with them.
Next, add our Project content type. Choose “Add from Existing Content Types” and choose project.
Save your changes and now, let’s see the list. Click on the New button drop-down.
You can create new Item (that only has a Title) and a new Project that contains a new project form with all the fields we selected for our content type. Here are the two forms.
So regardless of whether or not you’re in the Internal projects list or the Client Projects list, you’ll have the same form, but the data is stored in two different lists. This concept doesn’t even exist in a typical database. Try playing around with this. Go back to one of your lists and chose a bunch of content types. You’ll see some pretty impressive behavior:
Content types are quite powerful and I’ve just scratched the surface here. They’re used all over the place in SharePoint. In the MOSS Publishing and Collaboration Portal sites, content types are used to define the fields used in Page Layouts. This is great concept that helps “prescribe” the fields that users can fill out in when creating new web pages for public facing sites. And more at home, content types can be used with document libraries to define default document templates. For instance, you can define a default “contract” document for your entire organization. Then when users create new documents in a Document Library, they always have the latest contract boiler plate.
There’s certainly more to lists, document libraries and content types, but i hope this has given you a taste of the concept. It took me a while to understand them, but I’m glad it finally sunk in. Happy SharePointing.
