Umbraco DocType Inheritance

This is a post in response to the ongoing discussion about DocType Inheritance in Umbraco.

I am working on a large site with a lot of different doc types. They do all share some common properties – Breadcrumb name, and menu name for example. I also need to add Metadata fields to each of these document types at some point.

Niels is probably correct – “inheritance” would save me half an hour here, half an hour there. But I do still think it would make my life easier and take some of the tedium out of website development!

I have been giving this some thought over the last few days and wondered if some of my thoughts would be of use to anybody.

Aims of DocType Inheritance
1. Ability to inherit the properties defined in a base Document Type
2. When the base document type properties change, these changes should propogate to child types.

Examples of DocType Inheritance
1. Car website – base “Auto” doctype with child “CopCar” doctype
2. Metadata – all/most documents require Keywords, Description, Title, breadcrumb name

Simple Implementation
If the purpose of DocType inheritance is to re-use common fields, this can be achieved without making any changes to Umbraco and without even adding any packages to Umbraco (although, some Action Handlers could make the experience a little nicer).

I’m not saying this is a solution that everyone will want to use, but it is a possibility, and it works without any changes to Umbraco.

Meta Data
Here is a scenario:
1. a DocType called “BaseDocType” which has the properties “MetaKeywords”, “MetaDescription”.
The “BaseDocType” does not have a template assigned (@template=0)

2. a DocType called “Blog” which has the properties “blogImage” and “blogText” and “author”

3. a DocType called “Homepage” which has the properties “bodyText” and “featuredBlogPosts”

If we want all of our documents to use the properties in “BaseDocType” then the simplest way is to allow “BaseDocType” to be a child node of the other two – on the “Structure” tab of the Document Type, make sure that “BaseDocType” is an allowed child node.

WEBSITE
   |
   |-----------Homepage
   |                    |---------- BaseDocType
   |
   |-----------Blog Post 1
   |                    |---------- BaseDocType
   |
   |-----------Blog Post 2
   |                    |---------- BaseDocType

You can write some XSLT, Python, or in Umbraco v4 you can write some C# straight into the page, to retrieve the properties of the child basedoctype.

<xsl:variable name="baseDoc" select="$currentPage/node[@nodeTypeAlias='BaseDocType']" />
<meta name="keywords" content="{$baseDoc/data[@alias='MetaKeywords']}" />
<meta name="description" content="{$baseDoc/data[@alias='MetaDescription']}" />

Now we could add some more document types:
4. BaseAuto (With engine, transmission, topSpeed properties)
Again, no template should be selected for the base type (@template=0)

5. CopCar (With SirenColour and optional Doughnut holder)

Now you can re-use both the BaseAuto and the BaseDocType as follows:

WEBSITE
   |
   |-----------Homepage
   |                    |---------- BaseDocType
   |
   |-----------Blog Post
   |                    |---------- BaseDocType
   |
   |-----------Cop Car
   |                    |---------- BaseDocType
   |                    |---------- BaseAuto

@template=0
When writing menus, sitemaps, breadcrumbs etc you may already have come across ‘umbracoNaviHide’. This is a flag which can be used to tell XSLT not to render links to some pages.
I also use the @template attribute for the same purpose.

So, if @template=0 – do not render that page in any navigation or sitemaps.

Some Action Handlers
This could be made more user friendly by writing some action handlers. For example, if the user attempts to create a CopCar, then an action handler could automatically create the BaseDocType and BaseAuto child nodes.

This will require a more formal way of specifying the “inheritance” – so that the action handler knows which child documents to create. I think this could be done with a simple data type / label which identifies the child document types or by using the Document type “name”

Some tweaks
You could arrange your content in reverse – which would give a view which looks more like an inheritance tree.

WEBSITE
   |
   |-----------BaseDocType
   |                    |---------- Homepage

This would allow you to use Umbraco’s <GET_ITEM recursive=true> tag, and a little less XSLT.
However, you would need to redirect from the BaseDocType to its child node (using an Umbraco Redirect package?) which I think would make this structure unuseable.

The “real” thing
For those of you who still want “proper” doctype inheritance, this is how I think it could be done as an Umbraco Package using Action Handlers.

Naming convention: Use the DocType naming convention mentioned above (A extends B).
An ActionHandler or .NET event will fire when the DocType is saved. The action handler will check the name of the DocType – parse the “extends B” and add any properties from DocType B to DocType A.

If DocType B is modified, an ActionHandler or .NET event will modify all doctypes which extend DocType B.

I think you would also need to have a sensible naming convention for properties. For example, all properties of DocType B would be named “B.poperty” – to simulate namespaces and avoid duplicate variable names.

Special care would need to be taken to handle deep inheritance (A extends B, B extends C – so when C is modified, B would be modified, which would cause A to be modified).

Conclusion
So – thats how I think it could be done. What do you think?