The Envelope Pattern of Content Management

By Deane Barker on August 4, 2005

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.

  1. 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 defintion 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...).

content_objects -- -- -- -- -- -- -- - object_id object_type data_id date_created owner status ...

So a book record in the “books” table with an book_id of 463, would have a signature in this table like:

content_objects -- -- -- -- -- -- -- - object_id: 1875 (or whatever) object_type: "book" data_id: 463 ...

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.)

Comments (4)

Anonymous says:

James Higginbotham says:

A friend and I are looking at a bunch of different content management systems for a church Web site.

Not to deviate from your functional design pattern discussion, but I did the same CMS research over 2 years ago. Here is what I found: Give your experienced folks Dreamweaver, train the rest in Contribute, and move on. Only us developer-types understand CMS systems as they stand today. Most end users only understand documents. Macromedia treats web pages as a document that has a template (like MS Word). It then extends this standard concept to a site and access controls for users via Contribute.

There is more to be done in the kingdom than spend many hours messing with CMS systems that often confuse rather than enable. The only time CMS systems pay off is if they meet your exact needs, your target audience can use it, and they add value beyond simple HTML pages.

Maybe this is another functional pattern? Or, maybe its an anti-pattern. See a discussion about this approach and how it worked for me.

Alantin says:

Try MMbase.

Thomas Sigdestad says:

Check out Vertical Site from Enonic. Just what you’re looking for!