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.
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.
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.
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…
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…
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.
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!
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.
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 are where your site design flexibility comes from. In practice, they work very much like Rails’ 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.
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.
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.