An introduction to Metaprogramming

Metaprogramming in a nutshell is writing code that writes code. Here’s a really simple example:

<% 100.times do |number| %>
  <%= content_tag :strong, "hello" %><br />
<% end %>

Will output <strong>hello</strong> a hundred times.

This really simple example illustrates the power of metaprogramming; in theory, infinite lines of code can be written by just a few lines of your code.

The Rails source code is full of examples of metaprogramming, ever wondered how Active Record is able to provide methods like find_by_username()?

Here are a couple of examples of how you can clean up your code using metaprogramming techniques.

Some metaprogramming tips

Suppose you have an model, say Comment, that can exist in several states: unflagged, flagged, approved and removed. The comments table has an integer column called state that represents each of these states:

class Comment < ActiveRecord::Base
  # comment state is 1 by default and then changes as it is flagged, approved etc.
  STATES = { 
    :unflagged => 1,
    :flagged   => 2,
    :approved  => 3,
    :removed   => 4
  }
end

You want methods to check if the Comment is or isn’t in one of these states so you add the following:

class Comment < ActiveRecord::Base

  # comment state is 1 by default and then changes as it is flagged, approved etc.
  STATES = { 
    :unflagged => 1,
    :flagged   => 2,
    :approved  => 3,
    :removed   => 4
  }

  def unflagged?
    state == 1
  end

  def flagged?
    state == 2
  end

  def approved?
    state == 3
  end

  def removed?
    state == 4
  end
end

Great! Now you can call @comment.flagged? or @comment.approved? etc.

This is not ideal though, those four methods are really similar!

Defining methods on the fly.

By using “define_method” we can achieve the exact same thing as we have above but with much less fuss! Check this out:

class Comment < ActiveRecord::Base

  STATES = { 
    :unflagged => 1,
    :flagged   => 2,
    :approved  => 3,
    :removed   => 4
  }

  STATES.each_pair do |key, value|
    define_method "#{key}?" do
      state == value
    end

  end
end

For each key in the hash (the names of our states) a new method is created that checks if the object’s state is equal to value. Twelve lines of code condensed into 4 – Magic!

Lets also add methods to change the state of each comment:

class Comment < ActiveRecord::Base

  STATES = { 
    :unflagged => 1,
    :flagged   => 2,
    :approved  => 3,
    :removed   => 4
  }.each_pair do |key, value|
    define_method "#{key}?" do
      state == value
    end

    define_method "to_#{key}" do
      update_attribute :state, value
    end

  end
end

When we create a new hash, the hash itself is returned so we can call each_pair directly on the hash making this code even neater. We now also have methods that will change the state: to_unflagged, to_flagged, to_approved, to_removed.

If you have models in your applications that exist in one of several states then this technique could really come in handy to clean up your code. You may also be interested in the enum-colum plugin. Enum columns are like string columns but can only have limited amount of permitted values. This is a lot easier to keep track of than using integers like I have in this example.

Update

For more metaprogramming, check out this article on metaprogamming

Recently I was working on a project which required various permissions for each controller. A user could have permission to access one feature of the site but not another.

Here’s a great tip for keeping your rails controllers simple and DRY when working with multiple before filter conditions.

The before_filter method takes not only a method name as an argument, it can also take custom class objects as an argument. Here’s an example:

class OrdersController

  # run this before filter on :index, :show and :destroy actions
  before_filter PermissionCheck.new( :orders, :only => [:index, :show, :destroy] )

end

When requests are made to those actions that require this before filter, Rails will create a new instance of PermissionCheck and call it’s before() method (you have to define this method yourself). Here’s an example of the PermissionCheck class and how it works:

# lib/permission_check.rb
# Here we create a new subclass of Struct, an easy way to create a class with an attribute.
class PermissionCheck < Struct.new( :permission_name )

  # NOTE  - here it is assumed that you have
  # a) A method to find the current_user from the controller: ApplicationController#current_user
  # b) A method to check if the current_user has a specific permission: User#has_permission?
  # c) A method to redirect and notify the user if they do not have adequate permissions: ApplicationController#unauthorized_action

  # this is called from the controller automatically when we use before_filter
  def before( controller )
    # unless the current_user has permission...
    unless controller.current_user.has_permission?( permission_name )
    # redirect and notify user
      controller.unauthorized_action
    end
  end


  # after_filters can be defined in the same way
  def after( controller )

  end

end

To make things neater still, we can create a class method for this in ApplicationController:

class ApplicationController < ActionController::Base

  # Helper method to add this before filter to the controller
  def self.check_permission( permission, options = {} )
    before_filter PermissionCheck.new( permission ), options
  end

end

And our controllers now look like:

class OrdersController < ApplicationController

  check_permission :orders, :only => [:index, :show, :destroy]

  # etc...

end

class CustomersController < ApplicationController

  check_permission :customers, :only => [:index, :destroy]


  # etc...
end

Defining classes for before_filters and after_filters offers far more flexibility than simply using methods so, if your before_filters are starting to mount up and they contain a lot of similar code then defining a class may be a better solution for you.