Peter's Blog

I wanted to code some new features for one of my Radiant sites but I didn't really want to do it in terms creating new radius tags. What I am doing involves creating html tables from a database and doing this with radius tags has a few problems:

• it is beyond my understanding of what radius tags are capable of. For example, how can I pass a radiant tag the id of a record to display, if the record does not correspond to a Radiant page? I don't want to create Radiant pages for every record. The documentation for the tagging engine isn't strong and I don't have the time available to figure out how to use it.
• what if I want to port my application to some other platform? It would still run on rails but would not necessarily use the radius tagging engine: frankly I am happy using erb/rhtml for my templating (the 'end users' won't need to fiddle with the presentation of this stuff).

So the question came to be: how can one write regular rails code with Radiant? How to bolt some regular rails Model/View/Controller code inside Radiant. How to use my existing Rails knowledge? I had to study the mailing list for a while but the answer was very straightforward:

1. Install the share_layouts extension in your Radiant site.
2. Create a new Radiant Extension of your own using the neat tutorial.
3. Create a regular controller in your extension using the syntax from the extension tutorial, i.e.:

   script/generate extension_controller MyRailExtension myrails
   

4. Add the following code to your new controller so that it uses a radiant layout to render the page

   radiant_layout 'Layout name'
   

5. That's it!

You then carry on developing your application with regular rails MVC code in the app/myrails directory of your extension. The command to add models/controller are in the extension tutorial. The code generators create the stubs for the standard Rails testing framework so I have been testing my Radiant extension by following the tutorial in my Rails Book. This was one of my reasons for choosing Rails in the first place, you can buy books about it.

Radiant is very easy to extend, both by defining new radius tags or simply writing rails code. This makes it potentially a very powerful platform. There is nothing to stop me writing the administration pages of my extension in the same way as regular Radiant extensions and coding the presentation part in plain rails. I want to do some AJAX and the querying of JSON snippets would be done through my rails controller, once I read that part of my book

Incidently, on the subject of Radiant development I once complained how slow radiant development was on my pc. This turns out to be because of the way I was connecting to a Mysql database over an ssh tunnel for every page access. I ought to use sqlite for development on the pc as connection would be instant (I don't want/need a mysql server running on my development pc).

I have put together two projects using Radiant and I really like it. Radiant is Content Management System (CMS) based on Ruby on Rails. It is really easy to put a site up and it has an admirable level of simplicity and power. It can be set up such that every aspect of the site template (layout and css) and content can be configured through the administration pages and these pages are simple enough that non-techys can conceivably be trained up to edit their own content (the impossible dream). The only thing that cannot be managed through this are images, although there is a gallery extension that I haven't tried out yet.

One of my projects needed an extension to be able to handle 'what's on' type events. I tried out one on a list of third party extensions but it wasn't to my taste so I had a go at writing my own extension. I worked through the tutorial on the radiant site and it was very easy: it took me less than two hours to put together what I wanted. Radiant comes with generators that create the skeleton code for extensions for you, you just fill in the blanks. Extensions give you the ability to define your own tags to extend Radiant's tag language. You then mix html tags with your own tags so your tags provide the content, html provides the layout and css provides the styling.

Ultimately Radiant gives you a simple framework to build a site on and the extension facility gives you the hooks to take it pretty much wherever you want. You have full access to Ruby, Ruby standard library, Rails. Very nice.

There must be a downside and for me that would be that Radiant/Rails development can be very slow: ten or twenty seconds waiting for a page to update. Also the Radiant extensions seem to require rebooting the server to see the changes whereas in conventional Rails development it is not necessary to reboot the server (it's wonderful: change the code, switch to browser, bang the refresh button). UPDATE: running under Aptana, using Webrick the server does not need rebooting when the extension tag code is modified.

Radiant seems to be a small project and the SVN is not exactly buzzing. It is in a nice state as it is, functional and bloat-free. Maybe this is a good thing, the API's are not going to change under my feet.

Loving it.

I've always been in the habit of parking new web applications that I install in subrirectories under the root. For example, if I wanted to play with a Radiant CMS application on the www.petersblog.org domain I will install it in a /radiant directory under the main directory where petersblog lives and I can then access the Radiant web application at petersblog.org/radiant. This is a natural way to organise things, urls map directly to the file system.

However, many of the web applications I try (and I try many) are written on the assumption that they live in the root, i.e. directly in petersblog.org. When you try to use the applications they do not work correctly, the main manifestation of this being that when they generate web pages, the links on those pages are missing the name of the subdirectory that they live in: rather than a link to /radiant/list the page will include a link to /list. Radiant had this problem and there was no obvious easy fix (such as a configuration option to prepend a path to all links generated). I found a forum posting by the author that had a workaround that I didn't understand but then I came across what to me is a nicer general solution to any web application that may have this problem.

My Site5 hosting allows me to map a subdomain to a directory. This means I can create a subdomain such as radiant.petersblog.org and map it to any directory I like (it doesn't need to be near the petersblog directory). The application then runs in the root of this new subdomain and all links work just fine.

The first time I tried this it didn't work immediately. I altered my dns settings to add a new A record for the subdomain and within a few minutes it worked. I'm not sure whether this step was necessary but the delay did seem like a dns propogation issue.

Another advantage to using subdomains is that a directory listing of petersblog.org will not reveal them. I like this, I don't want my half-baked experiments laid out for all the world to see. Believe me, you don't want to see them either.