The Envelope Pattern of Content Management

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