By this point, the environment is set up, the CMS is installed, the content model is created, and roughed-in content is available.
Finally, it is time for templating. This is the moment you’ve been waiting for, when you actually get to generate some presentations of the content you’re implementing this system to manage.
Templating comes in two forms:
- The surround, which is the outer shell of each page
- The object, which is the specific object you’re presenting
Remember, the output of the object template is “injected” into the surround. Your object is templated, then this output is nested inside the shell of the surround.
In most cases, the surround has to work for all content. While having multiple surround templates can happen, it’s uncommon. In most cases, the template architecture has a single surround that is flexible enough to adapt to all content types. In some cases, surrounds can even nest inside one another, but this is also uncommon.
Templating the surround is unique in that it doesn’t execute in a vacuum. The surround is dependent on the object being rendered for information. The information can be of two types:
- Discrete: Information drawn from the value of one or more attributes
- Relational: Information drawn from the position of the content object in relation to other content
Additionally, the surround will often retrieve other content objects and data structures in addition to the object being rendered, to provide data for other sections of the page.
The primary navigation, for instance, is often explicit, meaning there is a specific content aggregation that drives it. Systems with a content tree might depend on the top-level pages for this, while other systems might have a specific menu structure of some kind that lists these pages.
Again, the “tyranny of the tree” can be a problem here – if the top-level pages are in that position for reasons other than being the primary navigation options, then how do you depart from this? It’s not uncommon to see explicit menuing for primary navigation, even in systems that otherwise depend on their tree for navigation.
For example, the surround often depends on determining the correct navigation logic. A crumbtrail, clearly, only makes sense in relation to the content object being rendered. Where that object is located in the geography will dictate what appears in the crumbtrail.
Additionally, many sites have a left sidebar menu. How do you know what appears there? Is it dependent on the current content object in some way? For instance, does it render all the items in the same section or group of content as the primary item? Is the menu hierarchical – does it “open”? How do we determine where and how it opens? Based on what criteria?
Despite this emphasis on global and relational information, some items in the surround are more directly contextual to the content being rendered. For example, a common element in the sidebar (the ubiquitous Related Content, for example) is dependent on the actual content item being rendered. It will extract information from that object to render itself. Do all objects have this information, or does the element in the surround have to account for varying information, and even hide itself if the primary object being rendered is not of a compatible type?
A question often becomes: do elements like this get templated in the surround, or do we template them as part of the content object itself and then inject the results into the surround? Content object templates can often be divided into “sections,” some of which can be mapped to places in the surround. Thus, if the related content element only appears for one type, then perhaps the more appropriate place for it is with the object templating, rather than the surround templating. If this surround element is required in more than one template, however, this is an inefficient duplication of code, meaning it should be abstracted to an include or moved to the surround template .