OK, so you already know I’m not extremely happy with the state of the CMS arena currently, and I promised you an update.

Andrew Eddie of the Mambo team and I have been exchanging some emails, each of us educating the other. I find that part of my previous rant was being addressed almost as I was ranting. There’s a style code that will load modules without the table wrappers. It wasn’t in the version of the docs that I was working from but the lastest set has it (dated mid-September).

So that solves everything, right? Wrong. I’m moving along towards being able to do what I wanted to do, but it’s still more often done over the tool’s objections than supported by it.

Part of the problem is philosophical, and part of it is technical. I’ve been head down in technical details too long (but I have managed to convince Mambo to let me place a “module” — Mambo-ese for a logical chunk of the web page, remember — floated to the right edge of a main content item, so it wasn’t a total loss) so as a break let me wax philosophical about it.

Each of the chunks of the web page are self-contained. The main content doesn’t wander around through the navigation, the ad banners keep to themselves, and the list of recent changes is way too snobby to be caught dead mixing with the synication links. That’s as it should be.

But where do the “lines of demarcation” get drawn? If I ask my CMS to upchuck some content, should it hand it to me packaged neatly with a bow, or should it just fill my waiting arms with a string of loose text? I would prefer the latter, but even while preferring it I can see why others would prefer the other.

Where do you want the work to be done? Most of today’s templating systems act like they’re working a loading dock. Boxes arrive, they check the manifest and stack the boxes in the appropriate piles. All neat and tidy. What could be better?

But what if you want a stack in a shape other than rectilinear? What if you want to “readjust” the contents of some of the boxes, so that what was in 5 boxes now fits in two slightly larger ones? As someone else remarked, why should a website have columns?

Are we approaching the idea with blinders? In one sense we’re used to the idea of stackable blocks, in terms both of programming and design. Programmers think about chunks of code as “objects,” they break tasks down into increments, and they view code that doesn’t respect boundaries as sloppy. And the grid model has been hanging around design studios for more years than I can count. It gave birth to the table-based design model, and current CSS-based design, while a step forward, still cannot handle grid design logic as well as I’d like.

As I was speculating, I considered what it was, precisely, I was asking for. A piece of content should know everything about what support functions it will be needing when it arrives on the page, but nothing at all about the location of those functions. A template shouldn’t know if any particular piece of content exists, but it should know precisely what to do with it when it comes knocking.

I idly wondered: create the page structure in xml. Each page could have a unique structure, each logical content chunk identified and given attributes identifying what support functions it would require. There would be no required order in which the chunks would be listed. Then the output engine takes those chunks and assembles them based on a set of rules provided by the designer: if this chunk is present, put it here, if not, let the space be filled by this other chunk. Somehow this output processor sounded familiar.

And shortly after that, it struck me. Am I describing XSLT?