So continuing on from where we left off in Part 1, you have a series of site columns to start with.  Time to build the types.  As with the site columns, you will want to use a feature for these.  The actual feature definition is actually pretty easy, but there are a couple of things to know up front.  As with the site columns, I opt to use the declarative approach to defining content types instead of the UI or the OM and deploy using features.  This is not, as we will see, without cost.  As with site columns, the XML schema is reasonably well defined here

Best Practice Number 3: Keep your content type definitions together too

Just like with the site columns, keep all of your content type definitions in one place.  It's much easier to keep track of everything.

Best Practice Number 4: Don't inherit from the base WSS content types directly

Andrew May has one of the definitive posts on how the mechanics of how content type inheritance works.  With that as a backdrop, take the time to set up your own base types on top of the WSS ones.  Having your own layer of indirection between the base types and the ones you will create allow you to change all your subsequent types more readily.  

Best Practice Number 5: Be aware of the lifecycle implications

So, once you've built and deployed these features, a problem crops up once you start using the content types.  When a content type is bound to a list, it's definition is effectively copied into the instance of the list definition.  If you subsequently want to change the definition of the content type, you can't reliably just change the XML definition and redeploy.  The problem is that when you redeploy the XML definition, SharePoint doesn't know to push the changes down to the lists that have incorporated the content type definition.  There are only two reliable ways to do this:

  • Use the User Interface to make the changes in the content type
  • Use the Object Model

My recommendation is to use a feature receiver to package the content type updates together with the XML definition.  If this feels a little sloppy to you, you aren't alone.  It bugs me a little bit too, but it's the best approach that I've come up with.