Handling Cookies and DHTML Effects with Ruby on Rails - 15.13 Extracting Code into Helper Functions
(Page 2 of 4 )
Problem
Your views are getting cluttered with Ruby code.
Solution
Let's create a controller with a fairly complex view to see how this can happen:
$ ./scripts/generate controller list index
exists app/controllers/
exists app/helpers/
create app/views/list
exists test/functional/
create app/controllers/ list_controller.rb
create test/functional/ list_controller_test.rb
create app/helpers/list_helper.rb
create app/views/list/index.rhtml
Edit app/controllers/list_controller.rb to look like this:
class ListController < ApplicationController
def index
@list = [1, "string", :symbol, ['list']]
end
end
Edit app/views/list/index.rhtml to contain the following code. It iterates over each element in @list, and prints out its index and the SHA1 hash of its object ID:
<!-- app/views/list/index.rhtml -->
<ul>
<% @list.each_with_index do |item, i| %>
<li class="<%= i%2==0 ? 'even' : 'odd' %>"><%= i %>:
<%= SHA1.new(item.id.to_s) %></li>
<% end %>
</ul>
This is pretty messy, but if you've done much web programming it should also look sadly familiar.
To clean up this code, we're going to move some of it into the helper for the controller. In this case, the controller is called list, so its helper lives in app/helpers/list_helper.rb.
Let's create a helper function called create_li. Given an object and its position in the list, this function creates an <LI> tag suitable for use in the index view:
module ListHelper
def create_li(item, i)
%{<li class="#{ i%2==0 ? 'even' : 'odd' }">#{i}:
#{SHA1.new(item.id.to_s)}</li>}
end
end
The list controller's views have access to all the functions defined in ListHelper. We can clean up the index view like so:
<!-- app/views/list/index.rhtml -->
<ul>
<% @list.each_with_index do |item, i| %>
<%= create_li(item, i) %>
<% end %>
</ul>
Your helper functions can do anything you can normally do from within a view, so they are a great way to abstract out the heavy lifting.
Discussion
The purpose of helper functions is to create more maintainable code, and to enforce a good division of labor between the programmers and the UI designers. Maintainable code is easier for the programmers to work on, and when it's in helper functions it's out of the way of the designers, who can tweak the HTML here and there without having to sifting through code.
A good rule of thumb for when to use helpers is to read the code aloud. If it sounds like nonsense to someone familiar with HTML, or it makes up more than a short English sentence, hide it in a helper.
The flip side of this is that you should minimize the amount of HTML generated from within the helpers. That way the UI designers, or other people familiar with HTML, won't wander your code, wondering where to find the bit of HTML that needs tweaking.
Although helper functions are useful and used very often, Rails also provides partials, another way of extracting code into smaller chunks.
See Also
- Recipe 15.14, "Refactoring the View into Partial Snippets of Views," has more on partials
Next: 15.14 Refactoring the View into Partial Snippets of Views >>
More Ruby-on-Rails Articles
More By O'Reilly Media
|
 This article is excerpted from chapter 15 of the Ruby Cookbook, written by Lucas Carlson and Leonard Richardson (O'Reilly, 2006; ISBN: 0596523696). Check it out today at your favorite bookstore. Buy this book now.
|
|
