Is a ContentType worthwhile/necessary in this situation?

Question

I'm creating a custom List Definition. I've previously been told that I should create a ContentType, and a ListDefinition from that. But this seems to mean a lot of duplication in my project files. So I'd like experienced opinions/direction in this area.

1. What benefits does a custom ContentType provide?

2. What limitations can not using a ContentType introduce?

---

Edit to Add Detail

So what I want to have is a List Definition, with two Instances. There are about 14 fields to be included in the list currently, and they're all input by the user.

There will be EventReceivers on the List for things like validation of the data, and also interacting with some external systems when certain conditions are met.

There will also be either a workflow or timer job which reguarly interacts with the list, and performs some action if certain conditions are met.

I've created the ContentType so far in Visual Studio using XML, but when I then make a ListDefinition in VS based upon it, it just seems to copy the whole thing (both the ContentType and Field tags) into Schema.xml.

So I'm wondering if this is really the best way, as if I need to make any changes to the ContentType (which is quite likely as it's an iterative development), I'll have to then replicate these changes in Schema.xml.

Answer 1

In addition to the other answers which have very good points, maintainability is also worth noting.

While technically it goes up a bit further, for simplicity sake I'll say that all content types at one point down the chain inherit their properties from Item. What this means is you can technically change anything about the Item content type and have it inherit down to the child content types. I accidentally renamed the Title field on the Item content type once and suddenly all lists had their Title field renamed. It was an interesting accident that confused many users.

A custom list, by default, will have a list instance content type that just inherits from Item (or document in the case of document libraries). That is why when you turn on management of content types in a list, the content type is called Item. You can then modify this content type to your heart's content without affecting the parent Item content type because technically it's a child of the Item content type at this point. You will generally get to a point where you like what you've got and if you want to reuse it you create a list template and use the template to give other sites the same functionality.

Now what happens when the business rules change and all these lists need new fields, different field names, fields that once held numeric values now need to be text values, or anything like that? If you had a custom content type that your lists were all utilizing you could go to that content type in the gallery, modify it, and have all content types on the site collection inherit the changes. If you used the default item content type that comes with a custom list then your parent content type is Item which most likely won't help you at all with the changes you need to make. Instead you will have to individually go to each list and manually make the change or automate it with programming if you have the ability.

Now I'll say that this is not 100% fool proof and still requires planning and maybe a little research, depending on the changes you want to make, so that you don't do something unexpected when you modify your content types. It can still save you a lot of work if you have lots of users utilizing the same prebuilt components - which is why I assume you are using a list definition instead of just manually building the list in the UI since that would save you a lot of time.

Like I said, the other answers are great and definitely cover a larger spectrum of why content types are great, but I feel this is a feature that really stands out that makes it worth mentioning.

Answer 2

Content type-based lists have a few advantages over those that aren't based on a custom content type. You can easily use content types to filter search queries. You can attach reusable workflows to a content type - which is useful if you have a list with multiple content types and different workflow requirements. You can easily re-use content types to create multiple lists. And, in my opinion, it's easier to create a list definition based on a content type because Visual Studio will generate the schema for you.

In the end though, it's one of theose architectural decisions that has no right or wrong answer. You just have to understand the ramifications of each and choose what makes the most sense for your project.

Answer 3

In Schema.xml file you must re-add your field declaration - that because in this case you are adding a field to the list definition. In other words, any new or existing fields available at a site collection must be added explicitly to the schema definition so that the list can use them. To connect the content type to the list definition, you also need to add the correct content type ID to the ContentTypeRef element in Schema.xml.

If you create list definitions from Content type with Visual Studio 2010, the wizard can add your Content Type and fields in Schema.xml.

Just make sure that, any new field added to the list (in future), also needs to be added to list content type in order to be accessible by the list item itself in the definition.

For further information:

How to: Create a Custom List Definition http://msdn.microsoft.com/en-us/library/ms466023.aspx

How to: Add a Content Type to a List http://msdn.microsoft.com/en-us/library/aa543576.aspx

Update: Now to answer you questions!

What benefits does a custom ContentType provide?

Custom content type is nothing but a Meta data. It will add additional information for the documents which is in the libraries/lists in SharePoint. Main advantage of using custom content type is very helpful in content searching, document routing, workflows, event receiver etc., following same contracts (Templates) for all the libraries or lists in the SharePoint site within the organizations.

More-ever, you can also have a template (Word, PowerPoint or any file type) that you attach to your custom Content Type. So for each of your document types (say Contract, Due Diligence Records and Executive Presentation) can have its own template.