Thursday, May 4, 2006

Radiant's Radiance

I’ve been playing with John W. Long’sRadiant CMS for the last few days and I have to say… I really like it. It walks the line between complexity and simplicity very well. And we all know how slippery a slope that is.

So what’s it all about? Why should you take the time to get familiar with it? Radiant is simple to use, simple to extend, and from my experience, simple to setup. Yet it enables the creation of complex websites. And it’s only an alpha version!

Tell you what, I’ll give you an overview of Radiant and you can make your own conclusion.

Hierarchical Pages

Ultimately, all CMS tools boil down to the fact that you are building web pages. And instead of obfuscating that by creating some abstracted terminology. Radiant calls it like it is. You create pages. You create site hierarchy by adding child pages. That simple.

Pages Admin

Behaviors

Behaviors are very powerful. You can think of them as plugins. Or as page enhancements. Or even as page types. Basically, they add functionality to a page. So instead of just being content, your pages can be more active—they have something to do! And we all need something to do.

Closeup: Behaviors

What they do depends on the behavior selected. For example, the Archive behavior changes the URLs of it’s child pages to mimic a blog-type URL scheme.

The real power of Radiant, I think, is in behaviors. Radiant includes a generator that creates the boilerplate code for new behaviors (and their unit tests) for you. So creating your own behaviors is really rather trivial. I’ve already created a few custom behaviors, and they are surprisingly compact.

In future posts I’ll make some of the behaviors I’ve developed publicly available, talk about how behaviors are developed, and what kind of things they are well suited for.

One of the ways that behaviors make a page more ‘active’ is by providing custom tags to the page they are applied to. Which leads us to…

Tags

For a in-depth understanding of the tag-system you should look at Radius. The short, short version: the tag syntax looks like namespaced XML tags. They aren’t, but look like it:

<r:children>
... content here ...
</r:children>

The interesting thing to me is how the tag output is based on context. For example, consider this snippet which loops through a page’s children and outputs a list of their titles:

h1. <r:title/>'s Children

<r:children:each>
* <r:title/>
</r:children:each>

(Yes, it’s generating Textile—More on that in just a bit…)

Notice that the tag <r:title/> is used twice, but with different output. That’s because of the context. When it’s called the first time (in the h1) it’s in the page context, so it shows the page’s title. When it’s called in the <r:children:each> tag, it’s context is the child page, so it shows the title of the child page.

Radiant comes with a lot of default tags that are very useful. I’ve only shown you a couple here. See the development wiki for more…

Text Filters

I will admit it. I am a Textile addict. I would, and mostly do, use it everywhere. So you can understand my delight to find it supported in Radiant.

Closeup: Filters

Text filters are pretty much what they sound like. They allow your content to be preprocessed before it’s rendered. It comes bundled with filters for my beloved Textile, and Markdown if you’re into that kind of thing. Of course, if you are just entering straight HTML you can choose to have no filter at all.

If you aren’t a Textile or Markdown person, you can always build your own filter. Radiant comes with a built-in generator to write all the boilerplate code for you!

Page Parts

I know what your thinking. Your thinking: C’mon M@, behaviors and tags do sound neat and all, but you know that pages can be complex things. They can be comprised of any number of different things, or parts.

Why yes, I do know that. Thank you. So does Radiant. You can create multiple content fragments, called page parts, for any given page. In fact, the main content of a page is just a page part, named “body”, that gets created automatically.

Page parts are one of those things that are simple, but that really allow you to build complex websites. They are shown as tabs in the admin UI.

Closeup: Page parts

Oh, I nearly forgot to mention that each page part can have a different text filter. Oh, and the filters are run after the tags, so you can have tags generate textile (or markdown, or your own custom filter format)... *whew*

Layouts

Layouts are where your site design flexibility comes from. In practice, they work very much like Rails’ layouts.

Layouts

Each page can be rendered with a different layout, or inherit it’s layout from the parent page. Multiple layouts are handy if you have different designs for different sections of the site, or different languages, etc.

Closeup: Layout selector

Snippets

Snippets are site-wide content fragments. You can include them on any page, or layout. I wind up using them for headers, footers, inline css, global sidebars, and main navigation.

Snippets

And More

There’s a lot of stuff I haven’t even touched on. For example customized 404 pages, multiple language support, page caching, publishing workflow, and lots more.

Be sure and check it out. I think you’ll be glad you did.

radiantcms.org

5 comments:

  1. Are you planning on building a sample site with it? I have it on my list of things to check out.

    ReplyDelete
  2. Nice article Matt. I'm looking forward to the next installment.

    ReplyDelete
  3. Matt, thanks for the nice overview. I built a CMS a long time ago, and am looking at learning what the current state of CMS tools is, with the idea of maybe "rolling my own" in Rails, or else going with something already out there - like Radiant...will definitely be checking it out further after this overview, lots of features I'm interested in are there.

    ReplyDelete
  4. Any follow-up articles on the way? I'm particularly keen to hear about the behaviours you've done, even if they are very simple. I'm a rails fan but have more experience in systems such as Drupal where you can easily extend the base CMS functionality with discrete modules. Having a Rails based CMS that handles the basics elegantly without overloading with features that should be separated into modules/plugins/behaviors/whatever sounds like a great platform upon which to build.
    Thanks for your writeup - just what I was Googling for. ;-)

    ReplyDelete
  5. Hi
    I noticed that you also have a CMS (Comatose). I've looked at both it and Radiant.... So far I have to say I prefer Comatose for it's cleaner integration with Rails apps. Radiant doesn't seem to provide an easy way to leverage existing contollers/views. Or am I missing something?
    Thanks!

    ReplyDelete