Tag Archive

Over the years, ActionController::Base#render has grown quite a few options:

render :action => "edit"
render :template => "products/show"
render :file => "/u/apps/other/warning.html"
render :nothing => true
render :inline => "<% @product.name %>"
render :update {|p| p.replace_html "A", "Error!"}
render :text => "OK"
render :json => @product
render :xml => @product
render :js => "alert('error!');"

Those options will still be in Rails 2.3, but the first three have a simpler alternative now:

render "edit"
render "products/show"
render "/u/apps/other/warning.html"

Rails will figure out whether you’re rendering an action, template, or file, and do the right thing. In addition, if you like symbols, you can render an action via a symbol:

render :edit

Ever write code like this in Rails?

if File.exists?(File.join(RAILS_ROOT, 'config', 's3.yml'))
  has_attached_file :s3_image,
  :storage => :s3,
  :s3_credentials =>  File.join(RAILS_ROOT, 'config', 's3.yml')
end

That particular snippet is from an application that optionally uses Amazon S3 to store images, if there is a configuration file for S3 supplied in the deployment. Well, you can clean that up a bit. First, although the RAILS_ROOT constant is still supported, we’ve had the prettier-looking Rails.root for months. Second, as of a recent commit to edge rails, Rails.root returns a Pathname object, so it directly supports the join method. Hence, the code snippet above can now be:

if File.exists?(Rails.root.join('config', 's3.yml'))
  has_attached_file :s3_image,
  :storage => :s3,
  :s3_credentials =>  Rails.root.join('config', 's3.yml')
end

A tiny improvement, but of such tiny improvements are a pleasant framework made.

I recently hit a situation where I needed to sort an array of ActiveRecord objects on a particular attribute. The catch was that in this case the array started out with the results of a find operation - but then it had a bunch more transient objects added to it that weren’t part of the database. Fortunately the Array#sort method makes short work of this. Given an array a of objects with an entry_date attribute:

a.sort! {|x,y| x.entry_date <=> y.entry_date}

Because this was the only sort I needed on this particular model, I decided to push the operation right down into the model:

class Receipt < ActiveRecord::Base
  def <=> (other)
    entry_date <=> other.entry_date
  end
end

Then the sort is much simpler:

a.sort!

Note that this technique only makes sense if your array isn’t coming straight from the database. If you are retrieving records from the database, you’re better off including an :order clause in your finder to let the database do the sorting.

There has been an astounding amount of invective and discussion over a recent addition to Rails. Briefly, if you have an array in Rails, you can now use ordinal numbers to get at the first ten members through aliases such as Array#second, Array#third, and so on. Some people are concerned about code bloat, some are concerned about lack of elegance, and DHH’s judgment in writing this bit of code has been seriously challenged.

Well, I’m not happy either - because the changes don’t go far enough. Let’s add one more method to Array and be done with it:

Class Array
  def by_ordinal(pos)
    self[pos.to_i - 1]
  end
end

With this simple addition, you can refer to Array.by_ordinal("3rd"), Array.by_ordinal("21st"), or even Array.by_ordinal("407th"). As a bonus, the naming of the individual members is consistent with Rails’ Inflector#ordinalize method. Please join me in pushing for this to be included in Rails core.

Here’s a commit message that showed up in the main Rails repository earlier today:

BACKWARDS INCOMPATIBLE: Renamed application.rb to
application_controller.rb and removed all the special casing that was in
place to support the former. You must do this rename in your own
application when you upgrade to this version [DHH]

Well, getting rid of special casing is great, and this commit does indeed simplify some of the Rails internals a bit. But I can hear some of my readers cursing: this seems like an arbitrary change just when Rails 2.2 is about to come out.

Fortunately, if you’re moving to Rails 2.2, this won’t affect you (yet). We’re close enough to 2.2 final that the main repository has been branched: there’s now a 2.2 stable branch (which is currently accepting very few bug fixes) and a master branch that’s targeted at Rails 2.3, or perhaps Rails 3.0. This change - and some other big changes that have been committed over the past few days - is on the master branch.

So, for Rails 2.2, don’t panic. On the other hand, if you’re tracking edge Rails closely, the next few weeks are likely to be a time of vast change (and instability) as some pent-up major changes hit the repository. Be sure you know what you’re cloning before you set up a new Rails application.

Maybe it’s just me and the amount of support and writing I’m doing these days, but I find myself fairly frequently looking at a bit of core Rails code and wondering “what that in release X”? To help figure that out, here’s a list of Rails version release dates (starting with 1.0) pulled together from the svn and git repos:

12/13/05 1.0.0

 3/22/06 1.1.0 RC1
 3/28/06 1.1.0
 4/06/06 1.1.1
 4/09/06 1.1.2
 6/28/06 1.1.3
 6/30/06 1.1.4
 8/09/06 1.1.5
 8/10/06 1.1.6

11/23/06 1.2.0 RC1
 1/05/07 1.2.0 RC2
 1/18/07 1.2.0
 1/18/07 1.2.1
 2/06/07 1.2.2
 3/14/07 1.2.3
10/05/07 1.2.4
10/12/07 1.2.5
11/24/07 1.2.6

 9/30/07 2.0.0 PR (Preview Release)
11/09/07 2.0.0 RC1
11/29/07 2.0.0 RC2
12/07/07 2.0.0
12/07/07 2.0.1 (2.0 final)
12/16/07 2.0.2
 5/11/08 2.0.3
 9/04/08 2.0.4
10/19/08 2.0.5

 5/11/08 2.1.0 RC1
 5/31/08 2.1.0
 9/04/08 2.1.1
10/23/08 2.1.2

10/24/08 2.2.0 (2.2 RC1)
11/14/08 2.2.1 (2.2 RC2)

It seems that a lot of the Rails applications I’ve been working on have a User model that has a many-to-many relation with a Role model, so that users can have a role like “admin” or “manager”, or even multiple roles. Along with this comes the necessity to conditionally show things in views. Recently I’ve started moving away from having explicit @current_user.has_role(”whatever”) calls in the views, to some code in the application_helper.rb file:

module ApplicationHelper

  def admin_only(&block)
    role_only("administrator", &block)
  end

  def manager_only(&block)
    role_only("manager", &block)
  end

private

  def role_only(rolename, &block)
    if not @current_user.blank? and @current_user.has_role?(rolename)
      block.call
    end
  end
end

Now in views I can easily mark off sections that should be displayed to only one user type:

<% admin_only do %>
  <!-- administrator content goes here -->
<% end %>
<% manager_only do %>
  <!-- manager content goes here -->
<% end %>

It would be easy to extend the role_only method to take an array of roles and check for membership in any of them, but I haven’t had need of that yet.

Hat tip to Aaron Longwell for introducing me to this technique.