Inspired by Nat’s post on inspecting what templates an item is inherited from, I wanted to post my own thoughts on how you would use this in practise. Often when I review template structures in Sitecore I get a feel for how well the template developer has of Sitecore presentation and ensuring flexibility.
A good practise that I advocate in these review sessions is to consider templates as abstract collections of fields. We then extend this concept to consider anything we make a content item out of as something that groups abstract groups of fields together.
What is important, here, is that I haven’t mentioned inheritance. As Sitecore is based on .NET and the single inheritance model, developers can often think of Sitecore inheritence in the same way.
This really doesn’t scale for multiple reasons:
- You restrict yourself to a single hierarchy of templates
- You end up with naming conventions for things you can make items out of in that hierarchy.
- You regularly end up having ‘special case’ templates to handle changing requirements.
In fairness, naming conventions aren’t necessarily bad so I won’t cover that further.
With that in mind, lets now twist this on its head and instead of doing bottom up design (a bug bear of mine) lets look from the top down. The top, in this case, is our presentation.
Here, we want to let our presentation components scale* by being bound to supported collections of fields and to allow related components to be interchangeable. This reuse requires that we also think about datasources, placeholders and compatible renderings but they’re a little off topic right now (one for another blog post).
By making a presentation component be bound to a set of fields, conceptually, all we need do is ensure that any item it shows is based on the template that groups them together.
Simple stuff so far. What’s important, now, is that we simply use multiple inheritance and build our concrete presentation template from our template ‘fragments’.
Then we can perform simple template tests in our code. If you are using something like Glass then obviously this extends to implementing multiple interfaces.
In my own codebase, I simply use an extension method on the Item instance which is very similar to the code ‘HasBaseTemplate’ in the previous blog post by Nat. Though whether you have it as an extension method or a method on your sublayout is your own preference!
I encourage you to try this out and change your inheritance models for your templates in your own projects to see how it works for you.
* Note, by scale I mean reuse, flexibility, page editor support etc (i.e. they scale in your solution).
This article is part of the Don’t Fight The Framework Series