As you may already know. From time to time I like to pay attention to things that seems to be common practices. Most of the time (not always 😉 ) related to modeling based practices. Today I want to talk about containers. You experience it from time to time, you want to store and maintain; comments, data, settings, archived pages, redirect pages, widgets or what else. Containers seems to be a nice solutions for this, but it doesn’t always feel right to save these data pieces in the page tree. I am going to share the considerations of using a container and share other features which maybe fits a "container use-case" better.
So the the Question is;
Is using a container a best practice? When do (or did) you use it in your CMS implementation and what are the alternatives?
What is a container?
The practice itself is not an Episerver only practice but more a general CMS practice. Containers are more of a datamodeling practice than that it is a feature (especially in terms of Episerver). One of the earlier articles I found (in the Episerver landscap) on this was the Container pages article written by Linus Ekström back in 2011. This article is based on Episerver CMS 6. Back in those days it was a very common practice. But since Episerver 7 we have a very extensive data model which has lots of features available where we previously had to choose the container practice for. So the question remains, is it still a best practice?
Where is it used for?
We see it used for;
- Re-usable pieces of content like; widgets, banners, menus (or what we maybe call today) blocks.
- Comments
- Tags
- Settings
- Archiving
- Translations
- Folder structures like; /2019/01/my-blog-post
I think that the next lines can be a guideline for your consideration of using containers or not;
- Your data need to be available in the page tree
- Writing your own implementation of IContentData is not an option
- Dynamic Data Store or an equivalent is not an option.
- Blocks are not an option (for what ever reason)
Blocks, data stores, …
Yes today, we have blocks. So make use of it. Don’t ever use the "containers" any more for thinks re-usable pieces of content like; widgets, banners etc. These are blocks.
We also have the the Dynamic Data Store for saving saving, loading and searching datatypes. These can be usefull for tags, translations, or other entities.
Then there is of course the possibility to create your own content providers, IContentData types and gadgets. Features which you can use and combine to solve a lot of use cases where you previously did use containers for.
Considerations (as an example)
I think a container is a nice solution for things like; forcing a nice manageable folder structure, like for blogs, news articles etc.
Also for archiving functionality containers are very usefull.
For settings we use containers most of the time. Not because we want settings to have a url. But I found it an editor friendly way to manage them in the page tree and I don’t like to have a big start/homepage page type with all settings in it (what we see a lot as well). By using a container strategy you can manage settings underneath the parent where they are used for f.e.; Global settings (settings for every site) under the root, Site settings (settings specific for a site) as a child of the site, Blog settings (settings specific to a blog) as a child container page of the blog root and so on. With a decent access rights strategy this can be a powerfull solution.
The mail templates as you can find them in the Episerver foudation example are i.m.o a perfect example where a maybe "missing?" feature can be solved perfectly with a container. Mailtemplates are basically mail(pages) without a url, but you still want to manage them as a content editor as they are pages. You can think about alternatives but for now this practice is very valid. Maybe they get their own feature in the future (like we have seen with blocks in the past ;-)..
Verdict
In my personal opinion you don’t want to "over" use the container practice. The page tree is for pages. And in the page tree everything need to have a url (in general). For tags f.e. we have nice packages (like geta tags), and so do we have them for managing translations. Blocks are a perfect way to manage "re-usable pieces of content".
On the other hand the page tree is very powerfull and right into the face of the content editor experience. For settings and mailtemplates we don’t have real alternatives (yet? (or look at Episerver Campaign)) and for archiving and forcing folder structures they are a good practice anyway.
(1) In the new Episerver foundation we also see the term "container" used for a block called Container Block. However this is a total different practice where I like to dedicate another article about.
Codevelo.us 