Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I've been researching a few different ways to create content types and I recently discovered that you can use the Object Model to do this. All of the examples I have found online typically use XML files to create content types.

I'm curious if anyone knows of some commonly accepted pros and cons of using Feature based XML files versus using the Object Model to create content types?

share|improve this question
1  
What version of the product are you using? Story is different for SP2010... –  Anders Rask Nov 17 '11 at 21:12
    
I am using SP 2010 –  Abe Miessler Nov 17 '11 at 21:35
    
Will you still use XML approach on creating hundreds of content types per site collection? –  user11703 Oct 30 '12 at 16:13

3 Answers 3

up vote 13 down vote accepted

One of the problems with content types (there are quite a few!) is that the design with site and list content types works very poorly with the declarative (XML) approach.

If you just update your Content Type manifest and re-install the feature new content types will be affected, but not all the list content types already "instantiated" from the site content type.

This is the main reason why people choose the code approach, since this effectively "unghosts" the content types placing all logic in the content database like the list content types.

In SharePoint 2010 the story is a bit better than in SP2007 though, since we have feature upgrade. Feature upgrade, as Jim mentions, gives you the possibility to add new manifest code to be run, and more importantly the AddContentTypeField makes it possible to add fields to existing content type, specifying if the changes must be pushed down through the list content types. More advanced scenarios can be handled in feature upgrade code. More on feature upgrade here.

In SP2007 i always took the code approach, and lots of my colleagues still do (some even outside of feature framework, calling custom code that reads XML definitions). However since feature upgrade addresses some of the upgrade issues with Content Types, i have fallen back to using XML. There are disadvantages with the XML approach with poor documentation on specific attributes, especially regarding taxonomy fields (read this article by Ari Bakker along with some of my comments at the bottom regarding DisplaceOnUpgrade and Override.

I often only create the most basic content types in XML and publish them to the CT hub. These could typically be sealed on high level and then be modifiable on the more specific levels.

I wrote up a longer answer some time ago on Stack Overflow: http://stackoverflow.com/questions/446451/sharepoint-what-happens-to-lists-based-on-content-type-when-content-type-is-upd

share|improve this answer

From the point of view of an experienced developer there is no major difference but there are points to consider.

Code approach:

  • More friendly for new developers, cause VS environment provides good features for investigating new API
  • You can debug it step by step, comment and use Watch tools, in comparison with XML where you just see the result
  • Before XML approach was not well documented, and certain properties puzzled developers

XML:

As for me, I prefer the XML approach.

share|improve this answer

This might end up as a 'whatever floats your boat' kinda question. I will add though, that whatever you choose, make sure it's consistent throughout the entire solution.

Remember that creating Content Types programmatically is done at Feature Activated level, which is after Feature XML is processed, so if you're provisioning Page Layouts, you'll need to ensure that you do the content types in a separate feature and that's activated before the one with your modules in.

As @default mentioned as I was typing this, you can step through code and have intellisense documentation of code, to the level you don't in XML. You could argue that with code, you have absolute control over every single thing that's happening when you do it via code.

Do also consider how you upgrade your content types if you write Feature Upgrades. This is easier when everything is done in XML, and might be trickier if done through code.

share|improve this answer
    
Just out of curiosity, which method do you typically use? –  Abe Miessler Nov 17 '11 at 19:34
1  
XML, because it's less 'wordy', fewer lines needed to do the same task, and requires less maintanence (write once, forget about it), and should be easier to upgrade. I got a feeling Anders Rask goes for code though... –  James Love Nov 17 '11 at 19:38
1  
Ended up going the XML route (even through it feels icky). Thanks! –  Abe Miessler Nov 21 '11 at 16:13

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.