Topic Archive: Radiant CMS

Getting semantic and DRY with microformats and Radiant CMS

Brian Dillard, Tuesday, April 1, 2008 @ 1:09 pm

I can now cross Microformats off my list of "technologies whose value I recognize even though I've never had the chance to use them in real life." Last week I created three hcards for the new Pathfinder website, one each for our Chicago headquarters, our New York office, and our head of sales. Now, if you've got a browser plug-in that can parse microformats, you can import our contact information directly into Outlook, Apple's Address Book or your PIM of choice.

A little background

Microformats, for those who don't immerse themselves in grassroots front-end technologies, are at the core of what's become known as the "semantic web." The basic idea is that by adopting a set of standardized markup patterns, we can create websites that are more easily parsable by both humans and machines. More from the "About microformats" page:

Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards. Instead of throwing away what works today, microformats intend to solve simpler problems first by adapting to current behaviors and usage patterns (e.g. XHTML, blogging).

The most popular and best-known microformat is the hcard, an HTML implementation of the standard vCard format used to store and exchange address and personal information in a wide variety of software applications. If vCards are basically electronic business cards that can be imported to or exported from your contacts manager, then hcards provide the same functionality in the browser.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

agile ajax

Yet another trick for Radiant CMS: Reusable snippets

Brian Dillard, Monday, March 17, 2008 @ 3:03 pm

In my endless quest to get DRY with Radiant, the Rails-based CMS for the new Pathfinder website, I made another exciting discovery last week: Snippets are basically just server-side includes that get interpolated into your pages before Radiant's custom tags are parsed. This means that you can create a snippet to, say, display a bunch of information about a page and then plug that snippet into any number of different contexts.

Consider the following three examples, all of which assume you've created a snippet called "whatever" that displays a few named page parts and the publish-date of a specific page within Radiant:

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

Radiant CMS and the DRY principle

Brian Dillard, Monday, March 10, 2008 @ 4:55 pm

Pathfinder is maybe a week away from deployment of its new website. I've posted several times previously about our experiences with Radiant CMS, the Rails-based publishing platform we're using to shield business users from actual code. Now that my Radiant work is coming to a close, I've got a pretty good handle on how build flexible templates without creating a maintenance nightmare. Sure, you're going to repeat yourself more with a CMS than with a custom, server-side templating engine. But you can get pretty darn DRY even in a tool as scaled-back as Radiant - all without conscripting your on-staff Rails developer to extend Radiant for you.

Pathfinder's primary objective in choosing Radiant was to allow content authors to create new pages using Textile - no HTML required. My own primary objective, as the keeper of HTML and CSS, was to build templates that would adjust to the needs of the content without requiring me to constantly create new layouts.

Our page design calls for a number of different content combinations: up to five discrete articles per page, and up to five discrete pieces of sidebar content. All sidebar modules require a special wrapper - two divs with specific classes applied - to achieve the correct look and feel. (Darn rounded corners.) To further complicate matters, most articles require their own special wrappers for CSS purposes, but some don't. If I'd built a different template to handle each possible combination, I would have gone insane the first time I needed to tweak the markup in all the places I had cut and pasted it.

Instead, my colleague Dietrich Kappe and I came up with the following approach:

• Create a library of named page parts that get plugged into the layout in a specific order.
• Educate business users about what these page parts are and how their naming conventions work.
• Create templating logic that renders only those page parts which are present on a given page. Radiant's built-in <r:if_content/> and <r:unless_content/> tags will do nicely.
• If multiple design treatments can be applied to the same named page part, create two alternate versions of the same page part and make them mutually exclusive in the rendering logic.
• Where advisable, make page parts inheritable from the parent page using the <r:content inherit="true"/> tag.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (3)

agile ajax

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:

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (3)

agile ajax

Radiant CMS: It’s all about the extensions

Brian Dillard, Tuesday, January 15, 2008 @ 11:16 am

As we prepare to overhaul Pathfinder's corporate website, my colleague Dietrich and I have been giving Radiant CMS a spin. An open-source, Rails-based content-management system, Radiant offers up the slogan "content management simplified." Although Dietrich has been doing most of the heavy lifting, thus far Radiant seems to live up to its tagline.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

agile ajax