This blog post is a part of a collection of posts about Information Architecture within Sitecore. The blog can be categorized as a “How we do it”, and gives our view about the setup of a flexible information architecture that can be reused in multiple projects.
In the previous post we’ve given an explanation how interface templates in a module are defined and how a page and a datasource template can be constructed from the flexible nature of the interface templates. The table below gives a list of template types that are defined in the Helix architecture:
| 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 |
In this post we will focus on the settings template.
Configuration and Settings
The Helix documentation says:
“We differentiate Configuration from Settings in that Settings are aimed at the user roles (editor, administrator) and Configuration is aimed at the developer or IT system administrator roles.”
According to this we have to create functionality to manage settings by the administrator or, more unlikely, the editor role.
Settings can apply on several levels. Mostly they are dictated by the modules in the foundation or feature layer. The scope of a setting can the site, or, in the case of a multisite or even a multitenant, apply to multiple sites or the complete project/tenant. Because of the correlation between the settings and the project structure, we combined these two
Anatomy of a multisite/multitenant project
My last few projects dealed with large multisite and multilingual sites. My customers need sites that are targeting countries all over the world as individual markets with their own strategy. Besides these multi market approach, customer like to add additional campaign in horizontal markets that target a worldwide audience.
Based on these practices we made definitions about what our content structure should look like. We recognize three main elements in our structure: the project, the respository and the site.
A project is a collection of sites and repositories. We made the assumption that all the functionality within a project is re-usable amongst all sites within the project. In a more detailed manner this means that all the sites can use the same lay-out and renderings, and the output of the renderings is in all case the same HTML. However, the style of these sites can differ by themes.
A repository is a collection of content and/or metadata. It can contain metadata that is used in the CMS environment and (multilingual) datasources that are re-used within the different sites. It also serves as container for pages that should appear in multiple sites. You can think about product information pages that are managed and translated by product specialists. From the repostiory this content is cloned to the target sites these products apply to.
A site is a collection of pages, implementing the base template IPage, starting with the Home page. A site contains mostly a local repository as well, containing local datasources for the renderings. A site has one or multiple languages, despite of the target audience of a site. A site re-uses the functionality from the project.
Besides these definitions about the function these folders, they are a unique location to add settings to, as can be seen in this image:
The Settings Module
The settings module is a combination of the anatomy of a project and the need to store settings. The definition of the settings module is:
| Name | Base templates | Fields |
| ISettings | Standard template | – |
| _SettingsProject | Standard template ISettings | SettingsProjectName |
| _SettingsRepository | Standard template ISettings | SettingRespoitoryName |
| _SettingsSite | Standard template ISettings | SettingSiteName |
With this settings module we can create the first version of the project scoped templates:
| Name | Base templates |
| Project | Standard template _SettingsProject |
| Repository | Standard template _SettingsRespository |
| Site | Standard template _SettingsSite |
Creating and adding module settings
Now we have a container for our settings, how does this apply to our modules? Assume we have a Cookie Message module. When thinking about het datamodel for this module, there is one single element that should be managed: the cookie message itself. Due to the nature of this cookie module, it will probably not be exposed as a rendering that can be added to a page. Most likely, the whole module is implemented on within the code and attached to the lay-out logic.
The scope of the cookie message is bounded to the site and it can be seen as a site setting. Thus we create a cookie message settings template, inheriting from ISettings:
| Name | Base templates | Fields |
| _SettingsSiteCookieMessageModule | Standard template ISettings | CookieMessage |
And by simply add this template to the base templates of the Site template in the project scope, we have created a method to store and manage the site settings for the Cooke module. The new version of our project scoped Site template looks now like:
| Name | Base templates |
| Site | Standard template _SettingsSite _SettingsSiteCookieMessageModule |
Because our feature module is depending on the Settings module, it makes also clear what the scope of the Settings module should be: the Settings module is part of the Foundation layer.
Summary
In this post I focussed on one of the template types in the Helix architecture: the settings template type. We connected the settings to the structure of a project and created thus an outline for our content structure in which we created containers for our project, repository and site settings.
MY THOUGHTS ABOUT... 