Rails’ design provides for a complete implementation of the Model-View-Controller (MVC) pattern. The model element in particular is implemented as a self-contained layer responsible for all interactions with the data storage sub system. As such the model offers the logically correct place to implement all business rules related to the correct handling of data throughout the application.

A well developed and tested model gives a great comfort and luxury that guarantees that whatever view-controller is put over the top, or how it is implemented, the integrity of the database with its respect for all business rules is complete and guaranteed.

This sounds like a bit of mouthful but is in fact very easy to implement. There is not actually very much that needs to go into a model therefore it is quite simple to ensure it is correct.

associations

Models define the relationships with other models. For example given a one-to-many relationship between groups and users (a group contains many users, a user belongs to exactly one group) requires the following associations:

class Group < ActiveRecord::Base
  has_many :users
end
		
class User < ActiveRecord::Base
  belongs_to :group
end

validation

Having all validation in the model is very powerful as a correct model guarantees complete correctness within the database. Rails contains a number of built-in validators. For example, if the user model requires that a username and email is given, all fields have a maximum length, the email field contains a valid format of email address, the password is confirmed in a separate field and the username is unique:

class User < ActiveRecord::Base
  validates_presence_of :username
  validates_presence_of :email
		
  validates_length_of :username, :maximum => 12, :allow_nil => true
  validates_length_of :email, :maximum => 80, :allow_nil => true
		
  validates_format_of :email, :with => /^([^@\s]+)@((?:[-_a-z0-9]+\.)+[a-z]{2,})$/i, :allow_nil => true

  validates_confirmation_of :password

  validates_uniqueness_of :username
end

Something of interest in the above example is the :allow_nil => true on some of the validation. We have said that the email address is compulsory, get when validating the format we allow it to be blank. Surely this is a contradiction? It’s not and the reason is to avoid multiple error messages if a compulsory field is left blank. If the email address is not given, the validates_presence_of will fail validation and trigger an error message. However, the validates_format_of would also generate an error as blank is not a valid address. Thus, tell the validation of the format to ignore a blank string.

Whilst the built in validators in Rails are very useful, any specific validation required which is not covered by them can be added simply by putting the code in a method called validate. This will be automatically called during validation. For example, a product with an effective date and an expiry date should validate that the expiry date is not before the effective date.

class Product < ActiveRecord::Base
  def validate
    errors.add(:expiry_date, 'Expiry date must not be before effective date') if !expiry_date.nil? && expiry_date < effective_date
  end
end

As we will see later, validation logic is also useful within the view as compulsory fields and error fields can be automatically marked for the convenience of the user simply by consulting the model.

attributes

Anyone used to a Java/Hibernate type environment will be familiar with the excessive repetition required to define a simple class and attributes - within the DDL to build the database table, the ORM mapping file, the Java class and finally the required getter and setter methods. Put a column in a table and by default Rails will do the rest for nothing. If the product table contains a column description, then the Product class will implicitly contain a getter method, description and a setter method, description=(description). This is exceedingly useful and saves loads of development time, but of course, can be expanded upon and overwritten if a particular application demands it.

For example, suppose the product name should be kept in the database in uppercase only. This can be achieved by simply overwritting the setter method.

class Product < ActiveRecord::Base
  def product=(product)
    self[:product] = product.upcase
  end
end

filters

Like the validate method, filters can be defined to be called at specific points in processing the model. For example, if a parameters table always has exactly one row, it will be added during installation and the model must not permit insertion or deletion of rows.

class Parameters < ActiveRecord::Base
  before_create   :filter_create
  before_destroy  :filter_delete
		
  def filter_create
    if !Parameter.count.zero?
      raise 'Insertion of multiple parameter records is not permitted.'
    end
  end
		
  def filter_delete
    raise 'Deletion of parameter records is not permitted.'
  end
end

Ruby on Rails migrations allows the complete definition of an Object Relationship Mapping in just one place. Using a more traditional approach of Java and Hibernate would require DDL to make the database table changes, possibly SQL to populate default values, XML mapping files and finally a Java class complete with getter and setter methods.

Rails achieves all of this in just one migration file. Each migration contains a couple of methods - one to move up to this version of the database model, and one to move down. Typically these might respectively contain code to create a new table and drop it.

For example, to add a simple users table:

class CreateUsers < ActiveRecord:Migration
  def self.up
    create_table :users do |t|
      t.column :username,  :string, :limit => 12,
                           :null => false
      t.column :full_name, :string, :limit => 40, 
                           :null => false
    end
  end

  def self.down
    drop_table :users
  end
end

The migration file does the job of the DDL and SQL allowing both database structure changes and data setup to occur. Rails’ axiom of convention over configuration removes the need for any mapping file or even the definition of the underlying class.

To show what else is possible in a migration it’s possible to add a unique constraint:

def self.up
  ...
  add_index :users, :username, :unique => true
end

Or add an admin user:

def self.up
  ...
  User.create :username => 'admin', :full_name => 'Admin'
end

As the contents of the up method are simply executed in sequence it’s possible to get around chicken and egg type scenarios. Suppose for audit purposes our user table holds a couple of fields to indicate which user created a new user and updated an existing user. Normally these fields would not allow nulls because they can always be populated. But who created the default admin user? It makes sense to be admin itself however, how can we defined the creator as a user who doesn’t exist? The solution is simple. Create the table allowing the created by field to allow nulls, add the admin user, set the created by field to this new user then update the table to no longer allow nulls.

def self.up
  create_table :users do |t|
    ...
    t.column :created_by, :integer
  end

  User.create :username => 'admin', :full_name => 'Admin'

  admin_user = User.find_by_username('admin')
  admin_user.created_by = admin_user
  admin_user.save
	
  change_column :users, :created_by, :integer, 
                                     :null => false

This is the first in a series of articles about developing a web application using Ruby on Rails. In this article we’ll look at installing Rails and creating a development environment.

To give a good realistic base for web application development we’ll install Edge Rails along with a suitable database and add some good options including Globalize for international support and database sessions. This example installs Rails in a Windows environment but there’s not much difference for a Mac or Linux installation.

ruby

Get the latest version of Ruby from the Ruby programming site. A standard Windows installer is available and we’re currently using version 1.8.6.

rails

After Ruby is installed you can obtain the latest stable release of Rails as a Ruby gem.

$ gem install rails --include-dependencies

database

You should already have your choice of database installed so we won’t cover that here. We currently use Rails with either MySQL or SQLite and in the past have used other databases too. The significant point during the Rails installation is to get hold of the appropriate Ruby gem for your database. For example, if you are using MySQL:

$ gem install mysql

create your Rails application

The remainder of the installation is required to be done within each application so create your Rails application now.

$ rails demo
$ cd demo

At this time remember to change the database.yml file to reflect your choice of database. For example:

defaults: &defaults
  adapter: mysql
  username: demo
  password: ...
  host: localhost
  encoding: utf8

development:
  database: demo_development
  <<: *defaults

test:
  database: demo_test
  <<: *defaults

edge rails

Rails is evolving quickly so we believe it is advisable to be at the edge. If you don’t you could find yourself missing new features and using code which will deprecate in a future version. We prefer to fix the version of Rails within each application so that you always now at deployment that everything will work as expected. Of course, you can refresh your frozen version of Rails from time to time during development to ensure you are as close to the edge at release as possible. At the same time, we’ll generate the rdoc.

$ rake rails:freeze:edge
$ rake doc:rails

database sessions

To store session data in the database…

$ rake db:sessions:create
$ rake db:migrate

…and don’t forget to uncomment the line in the environment.rb file to set the session store to be :active_record_store.

globalize

As much of what we do is international, we find it easier to build i18n in right at the beginning of each application. We’ll talk about Globalize in future articles but for now it’s a good idea to get it installed.

$ ruby script/plugin install 
     http://svn.globalize-rails.org/svn/globalize/trunk
$ rake globalize:setup