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.

Like engines, extensions allows developers to share not just “plain” Ruby code between applications (which is done through plugins), but also to share controllers, views and routes between them, as well as maintaining separate migration versions for each extension. One difference between engines and extensions I’ve spotted, is that while engines allows the developer to override and add individual actions in controllers, extensions allow only for replacing an entire controller.

Recently, John W. Long, creator of Radiant, wrote a nice tutorial on the basics of extensions, so if you haven’t had a look at that, I’d recommend it before proceeding with this article. The rest of this text puts focus on how to alter the behavior of Radiant to suit your needs by developing an extension.

I’ll use one of my own extensions, the first to be published as open-source; File Based Layout, as an example on how to override, modify and add functionality to the core of Radiant. I developed this extension to bridge a critical gap between “static” Radiant pages and “dynamic” Rails pages; the non-existent ability to let them share the same layout. To achieve this, I had to alter the Layout model and the Site- and LayoutControllers. This is possible through the dynamic nature of Ruby, but it requires some knowledge about “metaprogramming” which I for one didn’t have before I started to develop extensions.

Take a look at file_based_layout_extension.rb. The activate method, invoked by Radiant at the proper time, includes code in the Layout model and the Site- and LayoutControllers located in modules placed in the lib directory of the extension:

  def activate
    Layout.send :include, FileBasedLayout::LayoutExt
    SiteController.send :include, FileBasedLayout::SiteControllerExt
    Admin::LayoutController.send :include, FileBasedLayout::LayoutControllerExt
  end

As other extensions might also want to extend models and controllers using similar module names, I have opted to namespace the modules with FileBasedLayout. Also, to make the three modules available to file_based_layout_extension.rb, they have to be required using require_dependency as I have in the top of the file.

To be able to store the name of a physical layout file with the Radiant Layout, I had to add a field the layouts table; layout_file. This is done by adding a migration file to the db/migrate directory, and running the command rake db:migrate:extensions. I also wanted to validate the length of this field, and add a convenience method to the Layout model called file_based? (can you guess what it does?). This is done in the self.included method in layout_ext.rb by invoking base.class_eval with a block of code to be added to the class:

    def self.included(base)
      base.class_eval {
        validates_length_of :layout_file, :allow_nil => true, :maximum => 100, :message => '%d-character limit'
        include InstanceMethods
      }
    end

    module InstanceMethods
      def file_based?
        ! layout_file.nil? && ! layout_file.empty?
      end
    end

This is pretty simple, as we are merely adding stuff to the Layout class, but if what if we wanted to override stuff of, say, the SiteController? To create the File Based Layout extension, I needed to override some pretty low-level stuff in Radiant, in particular the show_uncached_page method, which is invoked when Radiant gets a request for a page not placed in the cache. It’s not enough to just include a module with this method, as I do in layout_controller_ext.rb, as methods in the class takes precedence over included methods.

Instead, I had to place my new show_uncached_page method directly inside the block given to base.class_eval in site_controller_ext.rb. This way, the new method is, so to speak, placed last in the SiteController class, overriding previous definitions of the method:

def self.included(base)
  base.class_eval {
    private

    def show_uncached_page(url)
      @page = find_page(url)
      unless @page.nil?
        if @page.layout && @page.layout.file_based?
          render :text => process_with_file_based_layout(@page), :layout => File.basename(@page.layout.layout_file, File.extname(@page.layout.layout_file))
        else
		...
   end

   ...

  }
end

And that’s it, really. When extending and changing Radiant or other Rails applications, the include, self.included and base.class_eval methods are your friends. There are, of course, performance penalties connected with especially class_eval, but as Radiant pages are cached, we don’t have to care too much about them.

What is an engine?
There are two aspects of Rails Engines: There’s the engine plugin, a standard Rails plugin that you need to install as any other plugin. This plugin enables you install the individual actual engines that you want to use – the engines are also seen as standard plugins from Rails’ point of view, but they won’t work without the engine plugin.

An engine works by allowing a large part of the standard Rails application structure (that is; the /app directory in your projects) to exist as a part of the engine. Where a normal plugin only compromises Ruby code (often core extensions and helper classes), an engine are capable of having controllers, views and models that behaves like they are situated in the “real” /app directory.

This allows you to reuse a lot of traditional support functionality such as authentication, authorization and user management, a wiki, a shopping basket, a blog, a CMS and so on. Several engine implementations of some of this functionality already exist, most of which can be found through Rails-Engines.org, and while the wonders of CSS can get you a long way in getting these engines to fit into the design of the rest of your app, you will almost certainly want to change some things. Enter Rails Engine’s biggest advantage: The ability to override individual views and controller actions on a pr. need basis.

Let’s say you want to add some text and images to the login view of the Login engine, because this action effectively will function as your frontpage. All have to do is to copy the view from the /app/views directory of the engine into the corresponding directory in your own views directory – and through the magic of the engine plugin, this view now overrides the view that came with the engine. Often you’ll also need to modify the behavior of various actions supplied by the engine – you do this simply by creating a controller with the same name as the controller in the engine with action you want to override in your own /app/controllers directory, and define the actions in the controller. The engine plugin is able to combine the controllers of the engine with the ones in your app, so you can both override actions already defined by the engine, and you can add actions to a controller defined by the engine.

When should you use an engine?
While it is indeed very convenient to be able to drop all this functionality into your app without writing any code your self, you should be aware that this ability is not the primary goal with the original engine plugin, and that many people sees a lot of potential problems in constructing an application from one or more engines. James Adam explained it like this to me in an email:

Rails and Ruby make developing applications very easy, so there’s very little reason why a competent developer couldn’t write every part of the application that they need, and not rely on any code from outside. Working in this way has significant benefits, because it puts you in a position where you intimately understand exactly how your application works. There are no mysterious black boxes.

So when should you use an engine? James’ original intention with Rails Engines, and the way he continues to use them himself, is by abstracting commonly used application “chunks” so they can be reused in his company’s applications:

Where I work, we are working on a varying collection of fundamentally similar applications, all at the same time. They don’t have widely different requirements in terms of their basic architecture (authentication, importing Excel data, reporting back, loading and storing data and so on…), so it makes sense that we only maintain a single version of each of these shared aspects. “Enterprise DRY”, if you like. This is why engines exists; we wrote the engines plugin to make it possible for use to reuse as much of this shared code as made sense in our situation, in a manner that was easy to maintain where generators aren’t, but easy to override when the situation required it.

As for myself, I gladly use the Login, User, Riki and Substruct engines in several applications, and while I cannot claim that it haven’t taken an effort to integrate the engines into the application, I’d still say that it has saved me a considerable amount of time – especially when I’m reusing an engine that I already know well. I guess the ultimate DRY-proof solution would be to abstract my own versions of these engines – probably not to share with others, but use in my own projects working just the way I want them.

Implementing the Login and User engines in your application
Now to the more tutorial-ish aspects of this article. In this section, I’ll explain how to implement two of the most commonly used engines in your application. I expect you to have a running Rails application with a functional database connection. I also suggest that you setup a Subversion repository so you can add the plugins as externals, but it is not strictly necessary, just DRY’er.

1. Install the Engine plugin
   1. Setup an SVN external attribute to point vendor/plugins/engines to http://svn.rails-engines.org/engines/tags/rel_1.1.3/ (or just download the files to that directory).
   2. The engine plugin is automatically loaded by Rails, and nothing visible happens until you install some engines. However, if you are running engines on Edge Rails, you should add this to the very top of config/environment.rb:

      # environment.rb
      module Engines
        CONFIG = {:edge => true}
      end
      

2. Install the Login and User engines
   1. Setup SVN external attributes to point vendor/plugins/login_engine to http://svn.rails-engines.org/login_engine/tags/rel_1.0.2/ and vendor/plugins/user_engine to http://svn.rails-engines.org/user_engine/tags/rel_1.0.1/.
   2. Create two new migrations; login_engine_schema and user_engine_schema, and copy the contents of the migration(s) in the db/migrations of each engine into each of the new migrations. This way, you can still create the entire database structure with the rails migrate, without the need for running specialized engine tasks.
   3. Add the required configuration and startup code to config/environment.rb. The configuration is well documented in the read me files, so I won’t dive into that here, but instead provide a sample of my setup:

      # environment.rb
      
      #####################################################
      # Engine setup
      #####################################################
      
      module LoginEngine
        config :salt, "not_my_real_salt"
        #...
      end
      
      module UserEngine
        config :admin_login, "admin"
        #...
      end
      
      Engines.start :login, :user
      
      UserEngine.check_system_roles
      Permission.sync rescue false # Ignore any errors here
      

   4. Add code to application.rb in order to add user authorization to all actions, and to make the user-logic available to helpers and models:

      # application.rb
      
      require 'login_engine'
      require 'user_engine'
      
      class ApplicationController < ActionController::Base
      
        # Login and User Engines setup
        include LoginEngine
        include UserEngine
        helper :user
        model :user
        before_filter :authorize_action # unless RAILS_ENV == 'test'
      
      end
      

      (Be sure to also include Login- and UserEngine in application_helper.rb to make support available to the views.)

3. Override views, actions and models as needed
• A view is overridden by creating a view with the same name in your own app-structure - not by modifying the view directly in the engine. For example; if you want to override the template for the list action of the user controller, simply create the file list.rhtml in /app/views/user/, and this file will be used.
• An action is overridden by creating the controller the action belongs to, and defining a function with the same name. For example; if you want to override the list action of the UserController to provide additional data to your list view, you should create the user_controller.rb file in /app/controllers/ and define the action:

  # user_controller.rb
  
  def list
    # ...
  end
  

• Overriding a model is a bit more complicated, since the engine plugin has no clever way of supporting this due to various reasons. However, in the Login- and User engines, it is possible to extend the User-model because it is implemented as a namespaced module, which can be included in your own model-file. So if you want to associate a user with, say, a log entry, you can create the file /app/models/user.rb with this code:

  # user.rb
  
  class User < ActiveRecord::Base
    include LoginEngine::AuthenticatedUser
    include UserEngine::AuthorizedUser
  
    has_many :log_entries
  
  end
  

# /test/fixtures/companies_controller.rb

  def setup
    @controller = CompaniesController.new
    @request    = ActionController::TestRequest.new
    @response   = ActionController::TestResponse.new
    @request.session[:user] = User.find(1)
  end