News Archive
PhpRiot Newsletter
Your Email Address:

More information

Decoupling Content Management

Note: This article was originally published at Planet PHP on 24 February 2011.
Planet PHP

Traditional content management systems are monolithic beasts. Just to make your website editable you need to accept the web framework imposed by the system, the templating engine used by the system, and the editing tools used by the system. Want to have a better user interface? Be prepared to rewrite your whole website, and to the pain of having to migrate content between different storage systems.

But none of this should be necessary. When web editing tools were more immature, it made sense for the same people to build the whole stack from database content models to web page generation and editing tools. But that was ten years ago, now we could do better.

Here is how a traditional CMS looks like:

As you can see, the whole system is a monolithic block. The CMS provides content storage, routing, templating, editing tools, the kitchen sink. Probably you're even tied to a particular relational database for content storage. Want to use a cool new editor like Aloha, or a different templating engine, or maybe a trendy NoSQL storage back-end? You'll have to convince the whole CMS project or vendor to switch over.

A much better picture would be something like the following:

In this scenario, the concept of Content Management is decoupled. There is a content repository that manages content models and how to store them. This could be something like JCR, PHPCR, CouchDB or Midgard2. Then there is a web framework, responsible of matching URL requests to particular content and generating corresponding web pages. This could be Drupal, Flow3, Django, CodeIgniter, Midgard MVC, or something similar. And finally there is the web editing tool. The web editing tool provides an interface for managing contents of the web pages. This includes functionalities like rich text editing, workflows and image handling.

The web editing tools have traditionally been part of the web framework, the framework serving forms and toolbars to the user as part of the generated web pages. But with modern browsers you could throw forms out of the window and just make pages editable as they are.

Common representation of content on html level

How would the communication between the web editing tool and the backend work, then?

First of all, the web editing tool has to understand the contents of the page. It has to understand what parts of the page should be editable, and how they connect together. If there is a list of news for instance, the tool needs to understand it enough to enable users to add new news items. The easy way of accomplishing this is to add some semantic annotations to the html pages. These annotations could be handled via Microformats, html5 microdata, but the most power lies with RDFa.

RDFa is a way to describe the meaning of particular html elements using simple attributes. For example:

typeof="" about=""

property="dcterms:title"News item title

AA Aproperty="sioc:content"News item contents

Here we get all the necessary information for making a blog entry editable:

  • typeof tells us the type of the editable object. On typical CMSs this would map to a content model or a database table
  • about gives us the identifier of a particular obj

Truncated by Planet PHP, read more at the original (another 4411 bytes)