Technology Toolbox

Your technology Sherpa for the Microsoft platform

Jeremy Jameson - Founder and Principal

Search

Search

Always Specify Element with Custom Content Types

Note
This post originally appeared on my MSDN blog:

Since I no longer work for Microsoft, I have copied it here in case that blog ever goes away.

I came across a nasty bug earlier this week in Microsoft Office SharePoint Server (MOSS) 2007 -- especially nasty because troubleshooting it primarily involved trial and error since there were no error messages displayed on the page, in the SharePoint log, or in the Windows event logs. I even attached the debugger and set it to break on all exceptions, but had no luck there either.

The problem was that the document properties form no longer rendered for our custom content types, or rather that it would only partially render. The toolbar was there, as was the footer displaying the content type, version, date created, and date modified -- just no fields whatsoever.

It turns out that when I "rebuilt" our ContentTypes.xml file to include all of our final content types, I omitted the empty <FieldRefs> elements that had previously been there. For example:

  <ContentType ID="0x0101009F5C14F1CF5847c7BBBADA9A8637DEAB0106"
    Name="Brochure"
    Description=""
    Group="Fabrikam Content Types"
    Version="0">
  </ContentType>

instead of

  <ContentType ID="0x0101009F5C14F1CF5847c7BBBADA9A8637DEAB0106"
    Name="Brochure"
    Description=""
    Group="Fabrikam Content Types"
    Version="0">
    <FieldRefs>
    </FieldRefs>
  </ContentType>

If you do not specify the <FieldRefs> element, then your documents will not inherit any properties from the parent content type (and the document properties form will consequently appear to be blank). Ouch.

I found nothing in the SDK that indicates <FieldRefs> is a required element, and according to wss.xsd, this is optional (i.e. minOccurs="0").

You might be wondering why we would have a content type that does not specify any additional fields. This is the result of a decision we made early on for our solution. I am currently helping a customer migrate from a legacy document management system that has over 100 "publication types." After a little debating over whether to create distinct content types for each publication type or to minimize the number of content types and instead have a "Publication Type" field, we chose the former because we perceive it as being more flexible and extensible in the future. Just because "Brochure" does not specify any additional fields right now doesn't mean that it will never have any custom fields.

Hopefully this post will save someone the hours I spent investigating this issue.

Add Comment

Optional, but recommended (especially if you have a Gravatar). Note that your email address will not appear with your comment.
If URL is specified, it will be included as a link with your name.

To prevent spam from being submitted, please select the following fruit: Strawberry

Watermelon
Grapes
Cherries
Pear
Strawberry
Apple
 
Please add 2 and 8 and type the answer here: