Rails composed_of validation

ActiveRecord allows you to declaratively write validations (e.g. validates_presence_of) in any ActiveRecord::Base models. In addition, the errors will be stored in the @model#errors collection and be used by various view helpers and methods like FormBuilder, error_messages_for, and error_message_on, wrapping a nice error CSS around the offending html form elements. But when you have a normal domain model object that is non-ActiveRecord::Base such as a composed_of type Value Object, you will not have access to these declarative validation magic methods. Today let me try to elaborate on how to use ActiveRecord::Validation methods in your composed_of objects in Rails 2.0.


(The following entry revolves around the assumption that you are using f.fields_for to create and assign value object domain models onto your ActiveRecord::Base models. Using this approach eliminates most value object creation code in your controllers, achieving "Skinny Controllers". To learn about, visit, check out the Rails composed_of &block conversion blog entry.)


Using the same example in the previous entry, let's include our ActiveRecord::Validation module into our Money class like such:

class Money
  include ActiveRecord:Validations
  
  attr_reader :balance, :currency
  
  validates_presence_of  :currency
  validates_inclusion_of :currency, :in => ['USD', 'EUR'], :if => :currency?
  validates_presence_of     :balance
  validates_numericality_of :balance, :if => :balance?
  
  def initialize(balance, currency)
    @balance, @currency = balance, currency
    @errors = ActiveRecord::Errors.new self
  end
  
  def new_record?
    true
  end
  
  def currency?
    !@currency.blank?
  end
  
  def balance?
    !@balance.blank?
  end
  
  def self.human_attribute_name(attr)
    attr.humanize
  end
  
  def balance_before_type_cast
    @balance
  end  
end

You will notice a couple things. One, I have to define the #new_record? method. This method is defined on all ActiveRecord::Base objects, but since our PORO object is not a record per se, we just stub it out. Also, we need to store a collection @errors of type ActiveRecord::Errors.

Depending on what validation routine you will end up using in Money, you may have to stub out different methods. For example, I am showing error messages with error_messages_for (more on this later), and it requires stubbing out self.human_attribute_name (as of Rails 2.0, but no longer needed in future Rails). Using validates_numericality_of requires me to stub out balance_before_type_cast. Also, the validation :if conditions requires me to add the question-mark methods balance? and currency?. Remember, this approach does not give you all the validation magic. For example, validates_uniqueness_of will not work because it assumes too much about your object being a normal AR model and needs access to a database. But in practice, your Value Objects should not need such validations, and in most cases they contain only simple one-off validations, and provide simple functionalities such as formatting like this and this.

After all these, let's see our ActiveRecord Book class.

class Book < ActiveRecord::Bases
  composed_of :balance, :class_name => 'Money', :mapping => [%w(balance balance), %w(currency currency)] do |params|
     Money.new params[:balance], params[:currency]
  end
  validates_presence_of :name
  validates_associated  :balance
end

The composed_of conversion block remains. You will notice the validates_associated :balance line as well. This tells your book instances that they should not be persisted should there be any balance validations failing, just like any normal validations you would write. By default, any failing balance validation will add an error message 'Balance is invalid' in your @book#errors collection. If you want to suppress that message from showing up, you can pass in option :message => nil.

So, to put it all together, here is the view and the controller code:

<h1>New book</h1>

<%= error_messages_for :object => [@book, @book.balance] %>

<% form_for(@book) do |f| %>
  <p>Name: <%= f.text_field :name %></p>

  <% f.fields_for :balance, @book.balance do |ff| %>
  <p>Balance: <%= ff.text_field :balance %></p>
  <p>Currency: <%= ff.text_field :currency %></p>
  <% end %>

  <p>
    <%= f.submit "Create" %>
  </p>
<% end %>

<%= link_to 'Back', books_path %>

To show error messages from multiple objects on the view, I am using the view helper method error_messages_for(*args). The :object option actually allows you to pass an array of objects (c'mon, you should know this trick about ActiveRecord by now. If not, check it out here and here).

def create
  @book = Book.new params[:book]

  if @book.save
    flash[:notice] = 'Book was successfully created.'
    redirect_to @book
  else
    render :action => "new"
  end
end

Again, a skinny, thin, sexy-looking controller action.

A normal Rails un-RESTful page as a resource... or can it?

An index page comes with Rails scaffolding. It is used to show a list of the "thing" you are CRUD-ing on. However, all too often we are tasked to show some pages that we aren't doing any CRUD operations on. Just a few examples:

• Dashboard page after user logs in


• The "Forgot your password?" page


• Tabs or subtabs of multiple lists


• List page showing multiple lists of different entities

A normal dashboard page isn't something you would normally CRUD on. It is more like a place holder page that a user sees the first thing after s/he logs in, showing many items of all sorts valuable to a user. In many Rails app, depending on what those items are, the dashboard page will end up being rendered by one of the items' index action. Worse yet, next time when you actually need that index page by that model, you have to call it something else, maybe 'list', and then play with the routes to get it wired up correctly.

class CustomersController < ApplicationController

  # The dashboard page
  def index
    @customers = Customer.find :all
    @products = Product.find :all
    @tasks_of_the_day = Task.find :all
  end

  # A list of customers
  def list
    @customers = Customer.find :all
  end
  
end

ActionController::Routing::Routes.draw do |map|

  map.resources :customers, :products, :tasks
  map.with_options :controller => 'customer' do |r|
    r.dashboard '/customers/list', :action => 'list'
  end

end

Here's a suggestion: how about put it in views/dashboards/show.html.erb, and, while you are at it, give it a DashboardsController? Then, put it in your routes.rb as a (singular) map.resource :dashboard, like such:

class DashboardsController < ApplicationController

  def show
    @customers = Customer.find :all
    @products = Product.find :all
    @tasks_of_the_day = Task.find :all
  end
  
end

ActionController::Routing::Routes.draw do |map|

  map.resources :customers, :products, tasks  
  map.resource :dashboard

end

By rendering the dashboard page in a completely different controller, you now have a very readable GET dashboard_path named route (GET: http://localhost:3000/dashboards), and you will not contaminate the index action of your other models' controllers with instance variables of all kinds. You also have a more readable routes.rb file.

One of the examples above for non-RESTful pages is the "Forgot My Password" page. Can you think of a good way to do it the Rails REST-ful way? Please go to Seeing Rails Resources Clearly to share some of your thoughts.