What options are available for dynamic page composition?

There are two divergent personas of editors. In one, they create pure content and leave visual presentation up to the designers, via templating. The opposite persona is “editor as artist,” where they create content and visually apply it to a page, carefully moving elements around, nudging and rearranging until the result is visually pleasing.

In reality, this is probably less about the editors, and more about the content. Both types of editors exist, and very broadly speaking, there are two types of content output – “templated” and “composed.”

• Templated content is highly structured and meant to appear the same in all situations. It’s not subjective, and editors aren’t permitted to rearrange the output to suit their tastes (“Let’s try the sidebar on the left this time…”). Templated content is the Diet Coke of CMS – it’s meant to appear the same in all cases; its uniqueness is only in substance, not style. Example: a press release or a help topic.
• Composed content is visually subjective. Not only is an editor defining the words and images, but the editor is defining the visual presentation as well. In this case, they can absolutely put that sidebar on the right, and add other widgets and elements to different areas of the page. Composed content is the chef’s artisanal creation of CMS – it’s highly subjective and subject to the whims and tastes of the editor putting it together. Example: the home page or a marketing landing page.

Functionality to create the latter is known as page composition – we are literally going to “compose a page.” Many systems now have support for this model of content delivery for some or all of their content.

The very idea of a “template” implies an external force (the template/front-end developer) is imposed on editors to coerce them into creating the same visual output every time – a cookie cutter, after all, makes the same cookie shape, every time. Page composition reduces this structural imposition, and transfers some of the control back to the editor.

Very rarely, an editor will get a completely blank page surface on which they can do anything. However, usually, they’ll be granted some freedom of visual and compositional expression for certain content that can deviate from the standard template to some controlled degree. Where to draw this line between freedom and consistency is a key question.

Page composition can be handy for the same reasons structure in rich text areas can be handy – editors now have a palette of elements they can add to pages, which can drastically reduce the number of content types needed in your model. If they can add a photo gallery widget to any page, then you don’t need to have a dedicated Photo Gallery Page type.

This sounds like the rich text structuring we talked about last chapter. And it’s very similar. However, instead of stacked or embedded elements structured in a single attribute, that model is extrapolated to the larger page surface.

Page composition usually operates on the model of zones on a page surface where editors can place and “stack” elements. Each zone can contain multiple elements stacked from top to bottom. Each element is self-contained, and renders independently of the other elements in that zone.

Elements in the zone can usually be reordered freely, often through drag and drop. Less ideally, you might see commands for “Move Up” and “Move Down” on each element.

Occasionally, elements can stack horizontally, though this is less common and gets logically tricky since the web has conventionally been a horizontally constrained medium. Some systems will allow you to specify a width on elements (“wide” or “narrow”) so they can stack horizontally, while others have you add some type of layout or column-based element to allow other elements to be stacked inside of it.

Some elements – like the layout elements mentioned above – can recurse. So an element that goes in a zone, might also have one or more zones inside of it. Zones and elements can therefore become a reverse tree that renders from the outer page “downwards.” In this case, the page renders each zone, which each renders their elements, some of which contains zones that render, and so on.

These zones can often be limited by type, so only certain element types can go in certain zones, and can sometimes be limited by count as well, so only, say, three elements can go in a certain zone.

Zones usually don’t have to be used. What happens to an empty zone is left to the template developer and whatever HTML the zone generates by default. Usually they simply don’t render at all, but they might still be surrounded by HTML constructs that leave a “gap” in the page.

Depending on the system, the same element object might be allowed to appear in two different zones on the same page, or even twice in the same zone. There aren’t many situations when the same actual element object would need to repeat, but it would be quite common to use multiple objects of the same element type — multiple Image objects, for example.

Occasionally, a system might allow specific zone assignment values, meaning configuration values or perhaps even attribute values that override the actual assigned attribute value for this object in this zone. This means a single object could be assigned multiple times, with some data variation that might cause it to appear completely differently each time.

Remember that zones usually just store references to other content objects, so there are sometimes dependency considerations with page composition. Deleting an object would necessarily delete it from all zones in which it has been assigned; this might lead to unintended consequences. Consequently, most systems’ dependency management will track zone assignments.