Are site columns and content types really worthwhile?

Question

I started doing Sharepoint development by the book. From the very start I was taught, create A site column -> A content type -> A list definition -> A list instance.

So the theory here is you have excellent reuse, and a logical structure. Your lists have managed content types, which in turn are made up of the site columns you create. All very nice.

But the more I started working with lists, the more I realized that SharePoint inheritance of content types isn't quite what I thought it was.

I thought, since I've taken the time to create the custom content types , I should really just need to reference these content types in the list definition. But instead I found that it simply didn't work like this. It might look like it could work like this, but in reality, I found I was redefining all the fields all over again in the list definition.

So my question is. Is it really worthwhile defining site columns and content types, when ultimately you end up having to define them again anyways for each list instance.

Isn't it just quicker to not use content types and site columns and just use fields in the list instance?

Answer 1

I know this is an old post, but incase somone comes across it, you do not have your list settings correct, or your content type is defined in the work place. In GENERAL (exclude content hubs for now) Content types are defined at the site level, and available to the sites under them. SO I typically (but not always) define the at the site collection root.

Second, for your list you need to enable management of content types (under the lst settings advanced tab). Then, go to the list settings and add from existing site content types. Your content type will be listed. Then when you select it the columns will be automatically added to your list.

One advantage (among many) is that you can have multiple content types in you list, and have metadata that applies only to that content type. So if you could have Requisitions, POs, Invoices all in the same library, but only have users see and enter fields that apply to the specific content type they are adding (For example, don't have the invoice number column on the requisition since it does not apply). (Whe uploading the documnet via the UI, you can select the content type for the item from the dropdown and the available fields change)

This one feature is a MAJOR usability enhancement for users. They Hate too many lists (since without content types to get correct metadata fields for entry each type needs to be in a seperate library) or figuring out which fields matter and which can be skipped (if all types exist in library). Of course you could write custom code and event handlers to accomplish a similar funciton, but that is comparitively WAY too much work.

Answer 2

It's all about what you're doing. You don't have to use content types; if they add nothing to your solution, and you don't need the re-use that content-types offer then no worries.

Where content types shine is when you really do want to represent different types of objects within a list/library.

Say for example you want to capture Product Reviews and create a list with a Product Review base type. From there you can break out into Video Game reviews, DVD Reviews, Book Reviews. Sure they might share some fields, but there's also potential for capturing additional fields specific to each type.

Alternatively, you may want to roll-up content types across a site collection into a CQWP. Not really possible without using Content Types in the first place.

Both examples are indicative of requirements I encounter frequently.

Answer 3

When i started sharepoint development, i went down the path of site columns, content types, list templates and list definitions for all my lists. It works good for the first deployment. But then when it comes time to upgrade, its a real pain. The schema files are used to create the objects, but once they are created, then they are disconnected from the definitions. Not to mention all the extra features/solutions you have to deal with. And the various errors that visual studio gives you. Not to mention content deployment.

Now I tend to treat sharepoint lists the same way i treat database tables. I have a CREATE script, and i have UPDATE scripts. I then dont have to worry about how sharepoint is going to handle it, it just works no matter how many times i run it, or where i run it. Or I just build the content type/list through the UI and record what fields need to be added.

I must point out, that content type/site columns are useful if you are aware of the limitations. eg you can attach workflows to content types, define a publishing page content type for site wide usage and attach page layouts, etc, but in my experience there is a way to solve the problem without resorting to the overhead.