[Previous entry: "Aspect and Aspect Dev"] [Main Index] [Next entry: "Cute"]

02/01/2001 Archived Entry: "Some thoughts on content management"

Looking at our requirements, it seemed to me initially that the best thing to do was group catalogue, conventional web content and templates all together under the banner content, basically meaning anything that we want to give the client (client being the customer company - we need a proper glossary!) the ability to change without having to involve us too much. With this definition of content in mind, the next challenge was to find a suitable existing CMS to deal with it all. However, recently I've realised that this might not be the best approach, and here I outline my thinking.

I'm still keen on the idea of grouping all client-changeable data as "content" and dealing with it all in as uniform a method as possible, mainly because I think that most of the features that you want from content management (source/version control, workflow, job tracking, audit trails, nice web interface with previewing etc.) should be applied to everything, from catalogue items to business rules, and it should all be deliverable in a single interface if possible.

The problem is that while the functions you want to perform on the content are all relatively similar, the content itself (in our case) comes in quite varying forms. CMSes that boast at being good at handling all different kinds of data are still used to dealing with content in discrete, isolateable chunks: an HTML file, an image, a Quicktime movie, whatever. Where it goes haywire is with catalogue data, which is relational, composed of multiple records from multiple tables. It's much harder for an existing CMS designed for handling individual objects to deal with that. The best compromise I've seen is to use XML as an I/O format for the data, so you're editing a text file but in submission it's fitted back in as relational data. I'm not sure how well this works yet.

But that's not the only problem. The value in enterprise CMSes is seen just as much in the repository service as the interface, and we at Sparza don't care about that, as we have a repository already. Existing CMSes have a very hard time decoupling from their repositories (which are usually Oracle schemas), and the chances are that our repository works in a completely different way.

It's worth, at this point, stepping back a bit and splitting a CMS into the traditional three-tier architecture:

Here are our requirements at Sparza, as I see them:

• We have a repository already, and we want the CMS to work well with it.


• We want a decent interface, but at the same time we want quite a lot of control over interface creation/customisation.


• We want it to not put us in the poorhouse.

We've already covered the repository. For ther web-based interface, it basically comes down to a useful set of JSP tags/beans with which we can easily string together some editing tools - this would work best with our team, who are already used to developing JSP. Ideally those beans would also be accessible through a Swing-based local GUI interface (though those are slightly harder to build).

That leaves the middle layer, which can be split into an interface which describes the relevant management interactions (is this content checked out? who by? where does it have to go next?) and the implementations of those interactions with the storage tier. As should be apparent by now, I'm thinking along the lines of implementing these as a bunch of EJBs.

I should stress that I'm not saying we should definitely forget about third-party CMSes and just build our own, but my thoughts are heading in that direction at the moment. Most CMSes are designed for pure content-based websites rather than catalogues, further more, they're designed to be out-of-the-box packages (though, in practice, they often need a lot of work to get going) that are all-in-one and thus not great at either integration or substantial changes. The situation may be different for catalogue management tools (I'm still trying to get a handle on those). Anyway, most "decent" CMSes cost a ton and it looks like we'd be throwing half of the package away while we toil for ages to get the other half working like we want it to. This may be a more straightforward solution.