The Envelope Pattern of Content Management

By Deane Barker • • 4 min read •
Author Description

CMS don’t need to have an intimate knowledge of the content they’re managing. Rather, they just need to know that they’re managing content in general, and leave the specifics to the implementation.

AI Summary

This post explores the envelope pattern in content management, emphasizing the importance of separating content from presentation. The author discusses how this approach enhances flexibility, enabling better content reuse and adaptability across various platforms while improving user experience and workflow efficiency.

A friend and I are looking at a bunch of different content management systems for a church Web site. We’ve been discussing the merits of the various approaches, and looking at some open source offerings like Mambo, Typo3, and eZ publish.

During this, I’ve struck upon a concept that I always knew in the back of my head, but never really articulated –

I don’t like content management systems getting too cozy with the content they manage. In fact, I don’t even like the system to know what content it’s managing, just so long and it knows it’s managing content of some kind.

You can consider a content object in two levels:

  1. The fact that it is a content object. This means it’s a…thing that needs to be managed. As such, it has some meta information that’s important: a unique ID, a status, an owner, a date created, previous versions, perhaps a template assignment, and node assignment in a content tree.

    The kicker is that you can know all these things about it without knowing exactly what it is. It could be a book, an article, a staff profile – it doesn’t matter. This meta information is common to a content object in general.

  2. The specific information about the content object. This is specific to what it is. If it’s a book, then title, author, ISBN, etc. If it’s a person, then first name, last name, email address, etc.

Level one as described above is an envelope. When closed, an envelope has some common elements: a stamp, a recipient’s address, a return address, a flap, etc. But we still don’t know what’s in it.

If we’re the post office, we have to manage this envelope. We don’t know what’s inside, and – generally speaking – we don’t care. It just has to get managed like any other envelope. The post office doesn’t have special procedures for love letters, “Dear John” letters, business letters, letters to Mom, etc. Letters are just letters, so long as they’re in envelopes.

So I get frustrated with content management systems that insist on knowing what’s in the envelope. These systems have special screens and options for different content objects, and creating a new one – if possible at all – requires you to write code. (Note that this frustration only applies to systems that claim to be general – domain-specific systems like blogging platforms which don’t claim to be anything but that are exempt.)

More often, systems like this have pre-defined content types that you have to live with (“page,” “folder”) because they didn’t architect their system in a way that lets them separate the envelope from the letter (see this post for more on open and closed content management).

Systems like eZ publish let you create a new “class,” which is essentially an envelope into which you stuff the definition of an object. eZ publish doesn’t care what your object is, because all it really cares about is the envelope. (See this screencast for a demonstration of creating a custom class in eZ publish, narrated by yours truly.)

Programatically speaking, you see “envelope-oriented” systems often done with XML. Documentum’s Web Publisher Pro was like this. You created an “object” in the repository, and that object just happened to have an XML file attached that contained the actual data of the object. Web Publisher didn’t much care what was in the XML file – it left that to you. It was just concerned with managing the object as best as it could.

I’ve just started a project with Ektron’s CMS400.Net and it seems to work the same way – even down to the XML format.

If you’re coding a system yourself, there’s a pattern to doing this. Create a “ContentObject” class, then extend it for whatever object you’re building – 

class Book extends ContentObject
{

}

The ContentObject class contains all the methods for managing an envelope. The Book class extends that with methods specifically for managing the “book letter.”

Even if you do the data model relationally (with a separate table for each object) you can have a central table that tracks all the objects in other tables, kind of like we discussed here when I wished for a global database ID (still waiting for my royalty checks…).

This implements the envelope model – the content_object record as explained about is the envelope, while the record it in the “books” table to which it refers is the actual letter.

So if you want to implement workflow or versioning or something, you just have to toss around content_object #1875, without caring in the slightest that it’s actually book #463. Sub-systems that only consider the envelope can be global to any kind of letter.

I’m looking for other content management systems (besides the three I mentioned) that handle content like I’ve rambled on about here. Can anyone toss any others out there?

(Don’t look now, but I just articulated a functional design pattern.)

Links to this – On Posting Practices December 27, 2006
Aaron Mentele is asking about posting practices for people who blog a lot. But while the first part of my prediction seems to be true, I can’t say the same about posting getting any easier. Deane Barker tells me he spends 15 minutes on each post with the exception of an occasional chapter on cms...
Links to this – The "Named Content Views" Pattern June 10, 2006
By concentrating on the different "views" a content object may have, you can simplify your content templating considerably.
Links to this – The Content Tree August 18, 2005
A while back , I mentioned the concept of a “content tree” in regards to content management. I cited this as a “functional pattern” and promised to talk about it more, but I never did. So, here goes – With every content management system (CMS) I’ve written, I always get back to the concept of a...
Links from this – Open and Closed Content Management June 20, 2003
Different CMS allow you to define your content in different ways.
Links from this – Global Database IDs October 1, 2004
Here’s a handy feature for a database… Tables can have primary keys, but what about a database-wide primary key? When a row is inserted, the “id” field would be populated with a numeric key that’s unique to the entire database, not just that table. Additionally, a two-column system table would...
Links from this – Functional Design Patterns July 6, 2005
Applications have patterns – ways of doing things that have stood the test of time. These aren’t object modeling patterns , about which books and books have been written, these are…best practices for how to solve a particular type of functional problem. Around my city, you see a certain style of...