Radiant CMS: Some tradeoffs, but they’re worth it

Brian Dillard, Monday, February 25, 2008 @ 2:39 pm

We're continuing to iterate on our redesign of the Pathfinder website using Radiant CMS, which I posted about last month. Now that we actually have IA and design artifacts and content for the new site, I'm getting more intimately acquainted with this Rails-based CMS tool. Our main objective with Radiant is to allow business users to create content in Textile without dirtying their hands in markup. I think Radiant will do the trick, but it takes some work to set it up.

Like a lot of UI engineers, I'm used to building systems that separate content from rendering. Usually, though, I've had a commercial-grade templating system at my disposal to help build and enforce this separation. I've used Tiles, Struts and various roll-your-own frameworks in the past with great success. Unlike those tools, however, Radiant is designed primarily for simplicity, not flexibility. As with Rails itself, Radiant encourages you to take the "happy path" and do things its way. Instead of fine-grained, n-depth templating, you get layouts, pages and snippets:

• A layout is a page-level template.
• A page is a bunch of content plugged into a Layout.
• A snippet is an include that can be plugged into either a layout, a page or another snippet.

What's missing? A module- or snippet-level layout. This makes it difficult to abstract away the presentational aspects of a recurring content block. Let's say, for example, that your layout has a sidebar with an arbitrary number of content blocks within it. CSS considerations demand that you apply a markup wrapper to each one of those content blocks, like so:

<div id="rail">	<div class="railModule">		<h2>Rail headline.</h2>		<p>Rail content.</p>	</div>	<div class="railModule">		<h2>Rail headline.</h2>		<p>Rail content.</p>	</div>	<div class="railModule">		<h2>Rail headline.</h2>		<p>Rail content.</p>	</div>	<!--insert as many rail modules as you wish--></div>

In most templating systems, you'd have a generic, module-level template for these rail modules, like this:

<div class="railModule">	<h2><include:headline/></h2>	<h2><include:content/></h2></div>

To invoke this template, you'd call it in a module-level include file, like this:

<railModule>	<headline>This is your headline</headline>	<content>		<p>This is content.</p>		<p>This is more content.</p>		<p>This is still more content.</p>	</content></railModule>

To assemble several such modules into a sidebar, you'd have another template, like this:

<div id="rail">	<foreach:railModule>		<include:railModule/>	</foreach:railModule></div>

But Radiant doesn't offer n-depth templating. You get page-level templates and that's it. So to accomplish something like this, you would have to create a page with named content blocks such as rail-module-1 ... rail-module-n. Then, within your layout, you'd have to create branching logic using Radiant's built-in templating tags, like this:

<r:unless_content part="rail-module-1">	<!--generic content for when there are no rail modules--></r:unless_content>

<r:if_content part="rail-module-1">	<div class="railModule">		<r:content part="rail-module-1"/>	</div></r:if_content>

<r:if_content part="rail-module-n">	<div class="railModule">		<r:content part="rail-module-n"/>	</div></r:if_content>

This approach gets the job done, but it has three drawbacks:

• It's less idiot-proof: Each rail module contains arbitrary content rather than named "headline" and "content" attributes. You have to trust your business users to remember rules such as "Each rail module must begin with an <h2> tag.
• It's less flexible: You have to do some hard coding. If you could have up to five rail modules, then you have to repeat your <if_content /> logic for each of those five modules. If somebody wants to create a sixth module on some page, then you've got to hack the layout.
• It violates the DRY principle: The markup wrapper gets repeated for each optional rail module in the sidebar.

Despite these drawbacks, Radiant still makes sense for a small- or medium-sized company like Pathfinder, where you want to shield business users from editing raw markup but you don't want the overhead of a full-scale templating engine and a bunch of custom code to deploy it. It's hard to give up the control of building things yourself, but for small-scale projects it's usually worth it. Sometimes, though, it just takes a little ingenuity to bend open-source tools to your will. Next week I'll look at strategies for getting DRYer with Radiant by using and abusing snippets.

Related posts:

1. Radiant CMS and the DRY principle
2. Yet another trick for Radiant CMS: Reusable snippets
3. Radiant CMS: It’s all about the extensions
4. Getting semantic and DRY with microformats and Radiant CMS
5. Ask a UI Guy: How should I structure my stylesheets?

Comments (3)

Software Development

Comments: 3 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   Thanks for that summary — I was trying to get my head around what Radiant seemed to be missing, but somehow couldn’t make it click until I read this post.

   btw, calling the ‘rail’ a ’sidebar’ would have made it easier for us rails devs to parse — I see “railModule” as a css class and I get all confused

   Comment by David P Reese, Sunday, March 9, 2008 @ 11:39 am

2. 

   @David: My bad. I picked up the habit of calling sidebars “rails” when I was a developer at Orbitz. This was before Ruby on Rails ever existed. You’re not the only one to be confused by this terminology that I’ve been trying to banish from my vocabulary.

   Comment by Brian Dillard, Thursday, March 27, 2008 @ 11:58 am

3. 

   Radiant is open source… why not contribute a patch?

   Comment by David Lowenfels, Wednesday, July 23, 2008 @ 2:39 pm

Leave a comment