Learning objectives
- Explain why content and presentation are separated
- Distinguish content, artifacts, and channels
- Understand templating, templating languages, and "the surround"
- Grasp content aggregation and its many variables
- Recognize "the tyranny of the tree"
1Content vs. presentation
Your content is an abstract ideal; the web page a visitor sees is just one presentation of it. Binding content tightly to a single presentation drastically limits what you can do with it. Kept separate, one source of content can flow to a web page, a PDF, an email, a mobile app, and an API. Three terms make this precise:
Content
The abstract information in the repository — no inherent format. The idea itself.
Artifact
A concrete deliverable made from content for a context — a web page, PDF, or email. One piece of content yields many artifacts.
Channel
A distribution outlet — the method by which content is consumed (web, email, mobile, social).
Remember WORM from Lesson 1? Content is written once but read many times. Because a piece of content is consumed far more often than it's created, it's worth investing serious effort in the delivery pipeline — that one-time cost is repaid across every consumption, forever.
2Templating
A process that transforms content into a delivered format — typically a mix of presentational markup (HTML) and logic that prepares content objects for output.
Templates are where content and presentation reunite at the last moment. Multiple templates can be applied to the same object to produce different artifacts for different channels. The mini-languages templates use — Twig, Razor, Velocity, Freemarker — are called templating languages. They're deliberately less powerful than the system's full programming language (for safety and stability) but support at least token replacement and flow control.
On a rendered page, only some elements come from the operative content object — for a news article, that's the title, byline, and body. Everything above, below, and beside it — the site header, navigation, footer, sidebars — is "the surround." Usually two templates cooperate: a surround template forms the outer shell common to all pages, and the content object's own template renders the article and is placed inside it. The concept predates CMS entirely — Server Side Includes and FrontPage's "Shared Borders" did the same job.
3Content aggregation
The intentional grouping of content for organization or presentation — a "latest articles" list, a navigation menu, a category page, a content tree.
Aggregation is one of the most important and complex aspects of a CMS. In fact, truly understanding a CMS often means understanding how it aggregates content — aggregation has a far wider "pattern space" than most other features, so mastering it is frequently what separates a basic implementation from a powerful one.
Aggregations vary along many axes:
Static vs. dynamic
A fixed, hand-picked set of items versus a live query ("all posts tagged security") that updates automatically as content changes.
Manual vs. derived ordering
Editors arrange items by hand, or the order is computed from an attribute (e.g. publish date, descending).
Type & quantity limits
Restrictions on which content types may appear and how many items are shown.
Permission & status filters
Automatically excluding unpublished or unauthorized content from the aggregation.
Flat vs. hierarchical
A simple list versus a nested structure like a multi-level menu.
By configuration or by code
Assembled through the editor's settings, or defined in developer code.
Organizing content often creates content. A curated "top 10 articles" list or a hand-built menu is itself a piece of content — it needs the same management services (versioning, permissions, publication status) as the items it groups. Aggregations frequently deserve to be modeled as content objects in their own right, and sometimes get their own URLs.
4The tyranny of the tree
Content trees (hierarchies) are everywhere in CMSs, and very useful — navigation can be derived from tree position, permissions applied by branch, and so on. But binding too much functionality to a single tree can make it "tyrannical."
In many systems, a content object's tree position can dictate its permissions, allowed types, workflow, URL, and template settings all at once. That's efficient — until your needs diverge. You might group content one way for easy permissions but want different template control than the tree allows. A good system lets configuration depart from the tree when needed. The tree also struggles when the same item must appear in two places: most systems solve this with a "main" location plus a placeholder reference elsewhere, and external links usually have to be modeled as their own content object (an External URL type).
Cognitive containers. Content is almost never consumed in isolation — it's experienced inside a container like a page, an app screen, or an episode, assembled from many individual objects plus the surround. That container may itself be content. Delivery is largely the art of assembling those containers well.
🔑 Key terms from this lesson
- Content / artifact / channel
- The abstract information, a concrete deliverable made from it, and the outlet it's consumed through.
- Template & templating language
- The transformation process and the safe mini-language (Twig, Razor…) it's written in.
- The surround
- Everything on a page outside the operative content object — header, nav, footer — usually a separate template.
- Content aggregation
- Intentional grouping of content; understanding it is often the key to understanding a CMS.
- Tyranny of the tree
- The problem of binding too much functionality to a single content hierarchy.
Review Questions
Test your understanding. Click each question to reveal the answer.