So I’ve been a Rails geek for well over a year now. And then I went to Merb Day Atlanta and lo, I was converted. I liked the cleanness of Merb. I liked the incredibly flexible routing engine. I liked that it had a much more “blank slate” feel to it.
Of course a lot of that is Shiny New Thing syndrome, and the difference doesn’t even matter any more because now Merb is going to be Rails, but whatever. That’s not the point of this post. The interesting moment came at the end of the day: Yehuda Katz (leader of the Merb project) gave the closing keynote, and one of the things he mentioned Merb needing was a good content management system that could integrate with applications. This was something I’d been kicking around in my head already – I like some of the ideas of Radiant in Rails but feel its architecture is a bit backwards in some ways – so I spoke to him afterwards about my needs and whether there was anything already going on. He offered a few opinions on the state of current CMS projects, then gave me his card and said “E-mail me.”
I did. The following is the text of the e-mail I sent to Yehuda on December 8th. He never responded. I take no umbrage at that; he’s a busy guy, and I’ve fallen down on most of my own e-mail at Escape Pod. But I’ve continued to toy with these ideas, and over the Christmas week I’ve begun committing some real code to the project. I’m sharing the e-mail in the hopes that others may have useful thoughts about this.
From: Stephen Eley firstname.lastname@example.org
Date: Mon, 08 Dec 2008 18:09:26 -0500
Subject: Merb Day - thoughts on a Merb CMS
It was a pleasure meeting you at Merb Day Atlanta. I’m the guy who spoke to you after your keynote, saying I had an academic society site to rebuild and a Merb CMS would be a very valuable component. You gave me your card and asked me to e-mail you. Hi.
I’ve done some serious thinking since then about the philosophy you expressed: that what’s needed isn’t just another Rails-like app, but a framework like MerbAuth built on strategies and “communication primitives.” I’m curious A.) whether you know of any work already being done in Merb toward that goal for content, and B.) if you have given any thought already to what that interface layer ought to include for basic CMS functions.
I’ll give you the basic outline of my own thinking, and if you think these ideas have merit, perhaps you may be able to point me to other people or resources that could help put this together:
“Content” is any page on a Web site not generated by an application controller or slice. It’s the spackle filling in all the cracks. Any possible path might have a content page, if the information architect decides one should be there. (But controllers take precedence in the event of pathname collisions. This is a fundamental difference from the /public directory, and one reason we can’t just pipe into it as static output.)
Ergo, the CMS system belongs at the default route, either after or in place of /:controller/:action/:id. I suspect this would be best done with a defer_to in routing, although an exception controller or Rack handler could be other possibilities. Wherever it goes, there’s an invisible (never in the path) controller that shows and manages stored content.
The four basic features of a simple yet useful content system (using Radiant CMS as a model of simplicity) are rendering, editing, metadata, and authorization. Hierarchy may or may not be a fifth. These are your “communication primitives” that can be implemented by separate strategies.
A strategy should support all of the CRUD methods for rendering/editing. The main CMS controller will be RESTful; it will pass its basic work to the different strategies via defined methods.
Strategy slices can store and retrieve content however they want – from a database, flat files, another application, whatever. In addition to showing the content itself, they’ll be responsible for delivering new/edit forms, other pages to manage errors, workflow or other optional features, etc.
On rendering, all strategies will be tried in order until one doesn’t return nil. If none do, it’s a 404. Edits and deletes will pick the same page that a render would. For adding new content pages, either rules can be defined or the user can be presented with a choice.
Application layouts should be used by the main CMS library to wrap content, so that there’s no obvious difference between content and app output. Defaulting to the main layout is obvious, but eventually there ought to be some mechanism (I don’t know where) for specifying an alternate layout.
The content system ought to be able to retrieve and search on page metadata (author, title, last updated, etc.) and provide helpers to the main application so that they can be used in layouts or other app views.
Authorization feels like a different set of choices unto itself, and should not be bound to the content strategy. I know there’s work on a MerbAuthz plugin; the content library ought to leverage that, or whatever other standard rises up.
Hierarchy is very common in the real world: sites are trees and pages have child pages. But I can’t decide whether children should be nested resources with a separate set of add/remove/list primitives, or whether it should just be a side effect of page path, with child listings just one more piece of metadata. I’d value your opinion if you’ve made it this far. >8->
Page state, versioning, and approval workflow are common CMS features, but they’re not external-facing and don’t warrant communication primitives. The individual strategy can implement them if it feels like it.
I’ve been speaking of ‘app output’ and ‘content’ as if they were exclusive, but in future iterations, it could be possible to have both on the same page: app views could invoke helpers that yield content from the CMS wherever the developer wants it. This could make inline help, etc. easier to edit.
…That’s what I’ve got so far. Any thoughts? Is there anything vaguely like this in progress that I could contribute to, or would you suggest I invent this wheel in Merb? Like everyone else in the world, I have too many projects in too little time, but if that’s what it takes, it’s what it takes. I just need to get this Web site off of the shitty ASP-and-Microsoft-Access (no kidding) base that it’s on right now, and I want to do it right the first time.
Thank you very much for your time and consideration.
Director of Technology
American Academy of Religion
404-727-7972 (O) 404-727-7959 (F)
Looking back on that e-mail now, some of it I’m already looking at and saying “Yeesh, I really worked to make that too complicated.” I have a slightly different vision now. But it’s where I started, so I submit it for your consideration. I’ll talk more about what I’m actually doing in a near-future post.