This is by design. Radiant has a fantastic infrastructure for extensions, and rather than imposing a lot of advanced functionality making the software harder to get started with for everyone, it lets each developer make his or her own choices.

Still, even with the official extension registry it can be hard to navigate the many extensions out there. Many people have asked me what I recommend for just getting basics such as reordering, image upload and menu generation. There is no final answer to that question, but this article covers 10 extensions that are compatible with the newest versions of Radiant and gives you functionality you can’t live without.

For everyone

• Reorder: Yes, you really need to install an extension to be able to change the order of your pages in the page tree. I think this will be built into Radiant 0.7 – hopefully!
• Paperclipped: Currently the most popular extension for adding upload of images and other files. Great user interface – highly recommended.
• Copy/Move: Once your website is live, you’ll often find the need to move or copy pages to other places in the page tree – this extension lets you do just that.
• Navigation tags: There is a tag for generating the menu built into Radiant, but it requires you to hardcode the pages. This extension allows you to build your menu in a similar manner, but draws on the actual published pages in the page tree.

For the slightly larger website

• Nested layouts: This extension is a real gem if you ask me. It allows you to have a master layout with header, footer, main menu and so on, and then setup other layouts “nested” within the master with, say, a custom sidebar or headline shared by a bunch of pages.
• Styles and scripts: If you want to be able to change all aspects of your website without deploying new files, there is no way around this extension. It allows you to store stylesheets and javascripts separately from your pages, while still being able to update them in the admin interface.
• Concurrent draft: Allows you to have one published version and one draft version of each page. That way you can work with changes to a page and preview them, without having to actually publish them for everyone to see.

For those who build their own extensions

• Shared layouts: If your extension includes pages that need to use the same layouts as the Radiant pages, this extension is a must. It simply lets you specify a Radiant layout in the controller just like you specify a Rails layout.
• Exception notification: Once you add your own extensions to Radiant it makes very much sense to be notified of any exceptions that occurs. This extension wraps the popular exception notification plugin which has a few compatibility issues with Radiant.
• Settings: I highly recommend that you let your own extensions be configurable through the standard Radiant::Config interface. This extension provides a tab in the admin interface for adding and editing these settings.

Many, many more great extensions exists for Radiant – I haven’t even mentioned my own! And while the official extension registry is a great initiative, you’ll find even more by searching for “radiant extension” on Github.

I wish I could claim to have been playing with Merb for a while and have some real insight into the framework, but to be honest, I haven’t. I still think this a very interesting news, though, and in my opinion this can only be good news for the Rails community. Already, the brilliant Merb guys are optimizing and improving Rails, for instance this 8% speed boost in using respond_to.

So, how can we expect the the merge to affect the Rails framework we know and love? Let’s peek into the possibilities of combining these two frameworks.

One change that seems certain, is changes to the routing system. “Plans are already underway to port the Merb router over to Rails. At the very least, you will have the option to use the Merb DSL syntax instead of the Rails hash-based syntax. We’ll see which one becomes the default.” Katz says. David explains how Merb concepts for rendering resources in different formats will be used in Rails 3, but with more intuitive or “Rails-like” naming.

Another change which is likely to make it into Rails 3 is slices, as indicated by Katz in a response to his own announcement. Slices are “similar to what Rails-Engines promise, except merb-slices are built into the framework” as Ezra Zygmuntowicz explains. This is exiting news! I’ve always been interested gaining leverage by having reusable application slices, and I’ve actively built and used both Rails Engines and Radiant extensions. Engines has previously been frowned upon by leading figures in the Rails community, but it has been improved to work in a quite clean and easy-to-understand manner since the release of Rails 2.0, and are in fact compared to Merb slices here. Radiant extensions are obviously only for Radiant CMS-based websites, but the diversity of these extensions illustrates the potential of getting support for real full-stack application slices into the Rails core. A project like Adva CMS also illustrates how it is possible to build high quality reusable application slices for the common good.

A third change I hope to see as a result of the merge is controller-based mailers and partials. ActionMailer has always been a bit of an ugly stepchild in the Rails framework, and the positioning of a Mailer as a sort-of model, but with templates, doesn’t seem logic to me. Merb has an AbstractController class that both mailers and partials (called parts in Merb) inherit from, which allows for a more intuitive control in rendering mails and parts.

I was curious to find out how the Merb community has reacted to this decision. The Rails community doesn’t seem to be overly concerned. Perhaps it’s because the merge of Merb and Rails are called “Rails 3″. Not “Merb 2″, not “MerbRails” – the names clearly signals that the merge will be done on Rails’ terms. While it has become popular in the Rails community to dissociate one self with David Heinemeier Hansson, I still think people sees him as a good security for not letting the Rails principles go in the merge.

I browsed through the more than 100 comments to Yehuda Katzs announcement of the merge, and while about half of the commenters simply expresses their happiness and agreement with the decision, the objections of the other half falls roughly into three categories: Technical, personal and economic.

The technical concerns are of course fully expected, and some of the more interesting are:

• “Does merging a lightweight framework into a bloated framework make the bloated framework any lighter?”
• “I really hope that merb will be able to continue it’s ‘no-magic’ attitude and bring that to rails without compromises”
• “I would have liked to see merb go further on its own just to push the envelope further”
• “How many planned advancements are being put on hold while Rails catches up?”

The personal objections is about one very visible person: David Heinemeier Hansson. I hold no grudge against David, so I shall only repeat one of the more curious comments in this category: “The big problem, as always with Rails, is DHH: a vainglorious, two-faced prima donna with a massive and fragile ego. He’s good, but not nearly as unique and amazing as he thinks he is. I went to Merb to get away from DHH. Ugh.” If many people in the Merb community feels like this guy, I understand if they are concerned that David will simply steamroller the philosophy of Merb. David has been fast to address these concerns, but the question is if just saying everyone should work on what the care about is enough.

The economic perspective of the merge is where things gets interesting. Rails is trademarked by David and synonymous with 37signals, while Merb is very closely linked to EngineYard. Two commenters really nail it down:

• “How has the ‘Opinionated Software’ philosophy of “Fuck You (DHH)” Rails become aligned with the ‘open’ and democratic philosophy of Merb? Is this some kind of preemptive marketing in advance of a joint investment in both Engine Yard and 37 Signals by a common investor?”
• “My suspicion turns to the fact that almost every Merb core team member is owned by Engine Yard. Something doesn’t smell right.”

It’ll be interesting to follow not just the architectural design choices made on the technical front during the merge process, but also how this will change the positioning of 37signals and EngineYard, and if the two companies are really warming up to some kind of close relationship.

The timeline for a first peek at Rails 3 – the union of Merb and Rails – is said to be RailsConf 2009 – 4 months from now.

My problem was this: I was developing a Radiant extension called tags_multi_site, which allows the tags extension to play nice with the multi_site extension. This required me to scope all tags within a site, so that tags with the same name could exist in different sites, but in the same physical database table.

The tags extension has this validation:

class MetaTag < ActiveRecord::Base
  validates_uniqueness_of :name, :case_sensitive => false
end

I needed to add :scope => :site_id, but I couldn’t touch the code of tags extension itself, since that would terribly un-DRY and not reusable for anyone else. I had to either modify the existing validation programmatically from my own extension or to remove it and add my own.

I went for the last solution. I quickly discovered that validations are saved in an array available as an inheritable attribute on the model (read_inheritable_attribute(:validate)), and that the built-in Rails validation are stored as Procs in this array. One could remove all validations added so far by emptying this array, but I only wanted to remove validates_uniqueness_of to stay as loosely coupled as possible.

Procs can’t tell much about themselves – they are mostly just there to be called. But I knew from the Rails code that each validation Proc is added from inside the class method of the validation. So, I just had to figure out a way to determine the method context the Proc had been declared in to be able to remove the right one.

I realized I could read variables from the Proc’s context by doing an eval with the Proc’s binding applied. I also found an expression somewhere that returned the name of current method by using the stacktrace information in caller.

All in all, the solution ended up like this:

module TagsMultiSite
  module MetaTagExtensions
    def self.included(base)
      base.extend(ClassMethods)
      base.class_eval {
        # HACK: Remove the existing validates_uniqueness_of block
        read_inheritable_attribute(:validate).reject! do |proc|
          if proc.is_a?(Proc)
            method = eval("caller[0] =~ /`([^']*)'/ and $1", proc.binding).to_sym rescue nil # Returns the name of method the proc was declared in
            :validates_uniqueness_of == method
          else
            false
          end
        end

        # Add new validates_uniqueness_of with correct scope
        validates_uniqueness_of :name, :case_sensitive => false, :scope => :site_id
      }
    end
  end
end

It would be easy to make this into a generalized method for removing Rails validations, but I think this issue is pretty rare. Usually people can just change or remove the original validation. Still, this example demonstrates fairly well how the trusting nature of Ruby allow us to make far-fetched metaprogramming hacks to solve our problems.

1. Vacation
2. When I have had the time to write, I have tried to prioritize my now almost finished master’s thesis
3. I got a lot of fun computer games and interesting books for my birthday
4. When I have had the time to write, but haven’t felt like writing on the thesis, I have felt I should prioritize the Summer Reboot documentation project for Radiant

Excuses aside, I think my latest contribution the the Radiant documentation base turned out quite good. It describes how to create a custom page type in Radiant in an extension, adding page tags, custom fields and other good stuff.

Check it out in the Radiant wiki.

(I’m headed for RailsConf Europe in the beginning of September, and I hope a lot of articles will come out of that as usual – hope to see you there!)