Thursday, January 7, 2010

Inheritance, Content Modeling & Sitecore

In my previous post I discussed the most elementary aspects of content modeling with Sitecore. When you are learning a WCM system, it's easy to stick with very simple content models. The risk in this is that content models in the real world are not always simple.

Until you encounter requirements that include overlap and interdependency it's easy to have an unrealistic opinion of how well your WCM models content. So far I have been very impressed with Sitecore's approach to modeling content - specifically its support for inheritance.

In this post I will cover inheritance and why it's such a great thing to have in a WCM.

What is inheritance and how does it work?
A data template is a collection of fields. Those fields can be defined directly in the data template, or they can be "inherited" from other data templates. When content is modeled, there is often overlap between very different content. Inheritance allows the overlapping fields to be moved into separate data templates that can be used by any data template that needs the fields.

Let's consider some content that might appear on a website: books, press releases and reviews. The following table lists the fields that are needed for each content type:

Data Template Name
Fields
Book
title, description, image, category, author, price
Press Release
title, description, image, category, date
Review
title, description, image, book, reviewer name


Using inheritance removes duplication by allowing common fields to be moved into more generic base data templates. The following content model takes advantage of inheritance:

Data Template Name
Fields
Inherits
Content Base
title, description, image
[none]
Content Meta Data
category
[none]
Book
author, price
Content Base, Content Meta Data
Press Release
date
Content Base, Content Meta Data
Review
book, reviewer name
Content Base


This explanation of inheritance may appear to contradict something I wrote about items above. I wrote that an item is based on 1 and only 1 data template. That is true of items, but it is not true of data templates. A data template can be based on as many different data templates as you want.

The Book data template's path of inheritance as seen in Sitecore. This example shows the Book data template inherits from the "Content Base" template, which inherits from the "Standard template" template, etc. The "Content Meta Data" data template is also included, but is not shown in this screenshot due to space constraints.

Then what does it mean if an item is based on a data template that is based on multiple data templates? A book item is an example of this. The book item is based on the Book data template, but the Book data template is based on both Content Base and Content Meta Data. This means that the book item is able to store content defined in 3 data templates: Content Base, Content Meta Data, and Book.

You might be tempted to think that a book item is based on 3 data templates, but I don't think that's technically accurate. When you create the book item you can only select 1 data template. The fact that you inherit from 2 other data templates is important, but it shouldn't be confused with the fact that the book item is based on only 1 data template.

Why should you care about inheritance?
There are many reasons to appreciate inheritance. Being able to reuse content definitions makes it easier to make changes later. Consistency is improved because common fields are defined once and used when needed.

But I think the best benefit of inheritance is ease of use for non-technical users. Remember, all of this inheritance is handled by the developer. The content authors never see any of it directly, but they reap the benefits. From the author's perspective, all of the fields are just there. There is no linking or connecting to a separate object in order to enter the values. This means the author can work on the content in one piece, as it exists in the real world.

What is life like without inheritance?
This may seem like an obvious way to do things, but not all WCM systems are designed this way. Consider RedDot CMS (now called Open Text Web Solutions Management Server) as an example. In RedDot, it is possible to move common fields into a shared component. This component is and always will be separate from the component that uses it.

While setting these separate components up is not any more difficult than with Sitecore, the effects are far reaching and significant. Instead of having to create one piece of content, RedDot requires multiple pieces of content be created and connected to one another. Each piece of content is independent each other, meaning that they have their own security, workflow and publishing settings. Content authors have a hard time understanding which pieces go together and which don't. When blocks of content are missing from the website, they don't understand how that can be.

So what ends up happening is the fields that should be separated out are duplicated wherever they are needed. This makes life easier for content authors, but can result in a lot of duplication of work and added complication for developers. On a large project, it is easy to forget all of the places where changes need to be made.

What's next?
Data templates and inheritance seem to be 2 of the most important concepts to understand when first working with Sitecore. Modeling content is at the core of a WCM system, and data templates and inheritance are at the core of modeling content with Sitecore.

Being able to define content is crucial, but if you don't have any way to display content, you might as well not have any content at all. My next post will cover my first impressions of the approach Sitecore uses to handle presentation logic.

Want to learn more?

1 comment:

  1. This was very helpful, everything is very clear.
    Thank you very much.

    ReplyDelete

Note: Only a member of this blog may post a comment.