Containers are a common approach when designing CMS content models. They allow Authors and Content Editors to organize content hierarchically. While containers allow contributors to group, reorder, and organize content easily, they also add a lot of dependencies to the content across the system.
Containers add complex scenarios for simple tasks, including:
- Publishing
- Delete + Unpublish + Localize + Unlocalize
- Workflow
- Translation
Effects of using a container model:
- “Where Used” filters are used extensively
- Large amount of content dependencies lead to performance issues
- Large amount of content manager transactions while publishing to ensure content integrity lead to stability issues
- Multiple Database Transactions during Publishing
- Complex content unpublish and deletion
- Complex Experience Manager implementations (Experience Manager is not designed to use Containers)
Content Integrity Example:
In the scenario below, Tridion will attempt to maintain content integrity by publishing all pages using component instances. This example would cause a link propagation issue if the following conditions were met:
- Text Block – With image component is published within a page
- Application Include Container component is published within a page
- Buttons Actions tray component is published within a page
- Button App Include is published within a page
Welcome to TridionDeveloper Brandon. Just a couple of points to enhance this useful posting.
From my experience:
– From the editor perspective – the removal of the ability to efficiently use Where Used directly from the GUI probably has the most impact. This means working out which page needs to be published adds (at least) one click to get to each page
– If using XPM – From the editor perspective – In our experience we’ve got this working in a couple of clients that use containers – allowing the continued use of the container model to reorder items without localisation of the Page (and also allowing the surfacing of a link to the content component too)
– If using XPM – From the developer perspective – this does add a requirement to manage the containers (and the relationship between Component Types and the respective Component Template) and surface this to XPM. We’ve done this on several occassions – basic containers don’t offer much resistance here.
– From the publishing (or rendering) perspective – The resolving complexity becomes most relevant when we are publishing (and unpublishing) from Components (in the dynamic model that is becoming much more popular now with the push of the DD4T approach). Here the business need to consider
– the benefits of the basic container model ‘v’
– the publish/render overhead during a release ‘v’
– cost to properly design, implement and maintain some sort of workaround
HTH.