Understanding SharePoint Journal Volume 1 – Issue 2. Developing SharePoint Content Types
This issue of Understanding SharePoint Journal deals with development of content types. Rather than focusing on a single solution like issue one we’ll be looking at several different scenarios and answer several different topics, all related to content types.
USP Journal Volume 1 – Issue 2 deals with the following aspects of content type development:
- Content Type introduction
- Visual interface using FormTemplates
- Inheritance
- Behavior using event receivers
- Content types as folders
- Custom XmlDocument solutions
Subtopics include:
- Using SPQuery to list data
- CustomActions on content types
- Best Practices on creating custom type IDs
- Manipulating content types in code
- Creating folder content types in CAML
You may also want to preview this issue. The first 12 pages are available as a free download here.
USP Journal Volume 1 Issue 2 is 71 pages (PDF download) and costs $14.95. All sales are handled by E-junkie, and delivery is instant. USP Journal offers a 30 day refund, no questions asked, if you are not satisfied with your purchase. Please send refund requests to uspj-refunds@understandingsharepoint.com and include the date of purchase, your name, and email address used to purchase.
Buy now :
You can add any discount codes in the shopping cart.
Posted under Issues
This post was written by furuknap on March 30, 2009
What about changes to Content Types that have already been deployed?
If they have been deployed using declartive xml then how do you update exisiting content types?
Do you develop content types use the API?
thanks
Clayton:
Good questions! Content types added through features are available to edit through the web interface just like any other CTs. You can, of course, restrict editing or visibility.
Regarding supportability, features do support upgrades so you can update the content types after deployment. However, as content types are ‘copies’ once they hit any lists, you may experience that your deployed content types are not updated.
Of course, you can overcome all these issues by developing your content types through the API, and while the specifics are not covered in this issue of the journal, I have a section in my book “Building the SharePoint User Experience” on this, where I use a feature to deploy a web-scoped content type thorough the API as an example.
.b
I ran into this issue as well – spoke with one of the sharepoint team one day and their response was – NOT to define CT’s using features – but use the UI – this actually works pretty well – if you think about it. The soultion – which you would use features for – is developed by a developer – but the Content types – which are a business USER concept is handled by the site designer. The info is stored in teh database so it is backed up and therefore would not need to be redeployed. It is a PAIN to try all this out in dev and then have to manually recreate it in prod however – That I agree with. Any solutions to that issue? -Andrew Connel has a stsadm commnand that creates all the xml from a set of content types – which can then be used to create a feature — I spose that could work – but it still requires doing any updates in the UI
Was that the Microsoft SP team? If so, I’d check their credentials or their sanity.
The UI is hardly well suited for creating anything but the simplest of CT structures, and you’re missing out on all the power. It’s like buying a new car because you need a storage device for your iPod. Sure, you can use it like that, but it’s terribly expensive and you’re not using it right.
I’m not sure who you spoke to who gave you this advice, but anyone who has been in any slightly complex SharePoint development project will attest to the UI as the least favorable option for creating CTs.
.b