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
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?
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.