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

There are several places online I've read to only create content types in feature XML. However, the reason for this seems to be to keep the content type as deployed in a feature.

As I understand it, content types can be created in four different ways

  • Web interface
  • Client Object Model
  • Server Object Model
  • XML

The first two, web interface and client object model, have the disadvantage of disconnecting the content type that is being used from what is defined in the feature definition (if it is defined in a feature at all). But it seems to me server object model executed in a feature activated event handler is still 'as defined in a feature' and would not cause a problem.

So, is there a problems with creating a content type solely in the feature event receivers instead of in the features XML?

I don't think I'm inclined to do so, as I would prefer it be done in one place. But are there problems or benefits in declaring the content type in XML and then modifying it as needed in the event reciever?


Louis:

I'm not really looking for information for a specific scenario, but general information so I can make up my mind on what 'best practices' I'm going to use. With that in mind, this is what I've come up with so far: - the client object model doesn't allow the content type to be wrapped in a feature for deployment, so it's not looking like a good choice. - the web interface (I'm assuming) is just another client and uses the client object model, with the added down-side of not being able to place the changes in a code repository. - the server object model is good since it allows for feature creation and deployment and is code repository friendly. - the XML declaration method has the benefit of being the least hassle, but it is limited in that it can not do everything and has to be augmented with the server object model.

So I am leaning toward server object model. The only question I really have left is should I use XML declaration at all. What I'm lacking is an understanding of what (if anything) happens differently between the XML and a server object model code-only approach. This is further confounded by the XML approach not being a full approach in itself.

So I come back to the same question again (stated a bit differently). I've been reading that it is a 'bad' thing to disconnect the content types being used from the XML definition, but have not been able to find any solid reason why. It would seem to me that as long as the content types being used are as defined in features (that is, not modified by the web interface or client object model) everything should be fine -- but is this true? What benefit does a feature defined in XML have over one that is defined in server object model in a feature receiver? Are there any?

Again, I'm not looking for opinions or such, just information about how the two approaches are handled differently under the hood.

share|improve this question
    
can you please explain your scenario ? –  Luis Valencia Aug 20 '10 at 22:05
    
Louis: I inlined my response under the break in the original question. –  David Culp Aug 22 '10 at 2:53

3 Answers 3

up vote 5 down vote accepted

As you mention, declarative content types had issues in SP2007.

Since you mark your question as a SP2010 question, the story has changed.

In SP2010 we now have support for feature upgrade. Feature upgrade gives you the possibility to either declaratively or programmatically upgrade features, and hence get existing activated features (SPFeature) up to par with the installed features (SPFeatureDefinition). Declaratively you have some limited possibilities including re-applying manifests and for content types we can add fields to an existing content type and force the changes to existing list content types: AddContentTypeField

You still dont get around using the object model entirely when creating content types, since stuff like lookups and taxonomy fields (which inherits from lookup) still need to get hooked up with the right references in a feature receiver, but in general you shouldnt have to use the object model for creating or upgrading features in SP2010

For more info on Feature upgrade: SP2010 Feature upgrade kitt by Chris o´Brien

How to manage your Feature Lifecycle using Feature Versioning article in DIWUG magazine by me :-)

MSDN reference on Feature Upgrade

share|improve this answer
    
Thanks, +1 for great references to read to get an even better understanding of this, but I'm not ready to mark my question as having been answered. –  David Culp Aug 22 '10 at 2:56
    
I'm going to go with an understanding that it doesn't matter how I create the content type as long as it is in a feature and I don't modify it afterward. –  David Culp Aug 24 '10 at 5:36

In many cases this is a matter of preference and in some cases you have to rely on one or the other method or even both.

For instance provisioning Managed Metadata Site Columns cannot be done using solely XML. Either you do a fully programmatic approach or a combination of CAML and code.

share|improve this answer

For me it depends on your scenario, you would want to use the OM if you dont know some properties when you are creating it. If you know everything about the content type to create the best way to go would be using the XML approach. I think its more organized and you dont have to write code for that.

share|improve this answer

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.