Approaches to managing web content

Jon Warbrick
University of Cambridge Computing Service
jw35@cam.ac.uk

The old-fashioned way

Emacs (or vi, or edit, or whatever)

Direct access to the document tree, or via FTP, SSH, etc.

Server-side includes

Pre-process documents before serving

e.g. Apache's SSI module:
<!--#include virtual="/templ/head.html" -->
<... document goes here ...>
<!--#include virtual="/templ/foot.html" -->

'Super SSI'

Using something more powerful than Apache SSI, for example PHP, assorted Perl solutions, ASP, JSP

Can normally 'auto-wrap' content with standard headers and footers

And lots of other stuff

The super-editor

Dreamweaver being the obvious candidate

Support for templates – perhaps even enforcing them

Manages upload/download

Might do bulk editing

Processing pipeline

Examples include Cocoon, AxKit

Starts with a common input format, often XML

Applies transformations, often XSLT

Can generate multiple output formats, e.g. XHTML, 'HTML-one-file-per-section', PDF, WML, ...

Database-driven

Content stored in a database

Typically browser-based editing

Probably supports workflow, multiple formats, etc.

Normally complex, often expensive

Some things to think about

Can/should you lock down your authors?

How to do transfers?

Preview vs. production server?

Content 'lock in'

URLs: friendlessness and stability

Caching

A brief overview of some ways of managing content on a web site.

This approach works OK for a small site, especially if it's all maintained by the same person and that person is technically cluefull.

But it doesn't scale to multiple maintainers and it needs the cluefullness.

It's also a nightmare if you want to make a change to the common content because it's typically duplicated in every file.

Typically deployed by putting common content into separate files which are then included.

Needs authors to start from a common template.

There's a common problem of arranging to include the document's title (and sometimes other data) inside a standard heading.

SSI's capabilities are limited.

Lots of systems that let you embed bits of programming language into web pages (or bits of web pages into programs).

The ones I'm interested in execute server-side.

Most can automatically add common elements such as headers and footers.

Most can also do other things like extract content from databases, processing form posts, etc.

Whole site management systems can be based around 'super editors'.

Can result in software and platform lock-in.

Most such systems are commercial, per-seat licenced.

Some systems support multiple origin formats, e.g. XML for documents, a database for more dynamic content.

Humans probably shouldn't have to author raw XML, so need an XML origination solution.

Multiple output formats froma single input is something of a holy grail, but it requires a 'rich' input.

This is the typical module for a commercial CMS

Browser-based editing is attractive because it's cross-platform, but it often provides only limited functionality which can be frustrating.

Features that you don't want add to complexity and can get in the way.

These typically need significant staff/time/consultant resource to implement.

This is an incomplete list of things to think about when choosing a system for managing content.

2004-12-08T11:39:47