This blog post is part of a collection of posts about Information Architecture within Sitecore. The blog can be categorized as a “How we do it”, and gives a view about the setup of a flexible information architecture that can be reused in multiple projects.
In the previous post about this subject, a high-level overview of an information architecture in the Helix context was given. It introduced a granular definition of features. In this post I like to give a more detailed explanation about the setup of the interface templates
Template types
The Helix architecture document gives a set logical template types:
| Template Type | Can have a page layout? | Exists is which layers |
| Interface template | No | Feature or Foundation |
| Page template | Yes | Project |
| Datasource template | No | Project |
| Settings template | No | All |
| Folder template | No | All |
| Rendering parameters template | No | All |
A detailed description of these template types can be found in the Helix documentation (http://helix.sitecore.net/principles/templates/template-types.html). You’ll maybe notice that, in contradiction to this documentation, in the table above the settings template is upgraded to have existence in all the layers.
Our first Content module
One of the most basic (business) objectives when you talk about content is the base of all types of content: it always starts with some title. Secondly, to share content, or to summarize the information, there is some abstract. And at third, most content is accompanied with an image.
This title, abstract and image can have an alternative function as well: they can function as the SEO data, the Open Graph data or the Navigation as well. Or, these data can be the fallback for more specific implementation in respectively the a SEO module, Open Graph module or Navigation module.
Because of this dependency, the Content Module should exist in the Foundation layer. The interface template definition of the module looks like:
| Name | Base templates | Fields |
| IContent | Standard template | – |
| _ContentTitle | Standard template IContent | ContentTitle |
| _ContentAbstract | Standard template IContent | ContentAbstract |
| _ContentImage | Standard template IContent | ContentImage |
Or as an image:
As you can there is a very large degree of partitioning in the module. Instead of the maybe expected single interface template, four interface templates are created, where there is also a completely empty IContent template.
In the introduction of this paragraph some reservations were made about the fields: information might have a title, an abstract or an image, and not necessarily all three at the same time. And because Page and Datasource templates are scaffold in the project scope, we need the ability to select zero, one or maybe all three the fields. Using the setup in this way, it aims us to do so.
At the same time, we are able to determine with one single question if the Content module is part of a project scoped page or datasource template: it the IContent template part of your base templates. If this question is answered positively, we know that at least one of the three fields is implemented in the project scope, and we can ask the module to give us an appropriate model for displaying the data.
A rich content module
A second module which contains functionality that can be re-used in projects is the rich content module. You can think of many examples where an editor should be able to add rich content through the rich text editor of Sitecore.
The rich text editor can be configured in multiple ways by attaching a desired Html Editor profile. Out-off-the box there are multiple profiles, which can be copied and adapted according to project specific preferences.
At this moment we are challenging an interesting situation: the configuration of the rich editor is set through the Source value of the template field. However, the rich text editor is created as a module on foundation or feature level, and there is no way to override the source value on project level. We’ll keep that as a future challenge and have our first implementation of a rich content module:
| Name | Base templates | Fields |
| IRichContent | Standard template | – |
| _RichContentBasic | Standard template IRichContent | RichContentBody |
| _RichContentMedium | Standard template IRichContent | RichContentBody |
| _RichContentComplete | Standard template IRichContent | RichContentBody RichContentImages RichContentVideos |
It’s important to note the name of the fields. Where the Content feature has three different fields, this feature has three times the same field: RichContentBody. The idea is that within the project scoped templates, one of the RTEs is used, based on the nature of the content written. In some cases, a basic text editor with only the ability to make text bold or italic is desired, while in other templates, a complete rich text editor, with all its capabilities is necessary.
Constructing a project template.
With these two simple modules we can create our first project scoped content template by inheriting the interface templates from the Content and Rich Content modules. But before we scaffold the template, we introduce two other interface template (which have to find their way in a foundation module):
- IPage
- IDatasource
The role of these templates is to make a distinction between all the content that has an url and all the content that is rendered indirectly through Sitecore renderings. This information can be useful in the case of search for example: the search results should only contain content that inherit from the IPage template, because this content has an url.
With these interface templates we construct two project scoped templates: a content page template and a content datasource template. It will be clear that these are simplified examples:
Summary
In this post I defined the interface templates for two modules. A characteristic of this interface templates is that each module contains one empty template which is prefixed with an “I”, using the naming convention: IModulename.
The fields of the module are setup in a flexible way. Thus, the project scoped page and datasource templates can inherit only these fields that apply in the project. Because all fields inherit the IModulename interface template, it’s immediately clear which modules are applied to the project scoped page and datasource templates.
In the next post, I will focus on the Settings templates and how it fits in this granualar approach of Helix modules.
MY THOUGHTS ABOUT... 