Travis on Rails

Working with the flash hash

Sun, 17 Aug 2008 00:00:00 -0400

The flash hash is what Rails uses to display messages (both notices and errors). Since it's a Hash, you can assign any key/value pair that you want, but I tend to stick with flash[:notice] for a success message, and flash[:error] for an error message.

In my opinion, using the flash hash is a little confusing. I haven't come across a book or tutorial that fully explains how to control it properly. So, here are the options for using the flash hash in Rails.

flash[:key] and flash.now[:key]

The following method shows how to best use the flash hash:

def create
  @user = User.new(params[:user])
  respond_to do |format|
    if @user.save
      flash[:notice] = 'User was successfully created.'
      format.html { redirect_to admin_users_path }
    else
      flash.now[:error] = 'The user could not be created'
      format.html { render :action => 'new' }
    end
  end
rescue Exception => ex
  logger.warn('ERROR: ' + ex.message)
  flash.now[:error] = 'There was an error creating the user.'
  render :action => 'new'
end

Notice that I use the flash hash in two different ways: flash[:key] and flash.now[:key]. The way I use it depends on when I want it displayed. The flash[:key] usage should only be used before redirection, because it makes the object available for the current action and the next action. The flash.now[:key] usage should be used when you only want the flash object to be available to the current action.

Here's an example why you shouldn't use flash[:key] without redirection. Let's say this is your controller:

class MainController < ApplicationController
  def index
    flash[:notice] = 'Welcome to the site!'
  end
  
  def profile
  end
end

When you visit the index page, you'll see the message 'Welcome to the site!.' If you then click a link from the index page that takes you to the profile page, you'll still see the message 'Welcome to the site!' because the flash[:key] is available to the current action and the next action.

Displaying the flash

Here is a really helpful method to display the contents of the flash hash that I modified from one of Ryan Bates' awesome Railscasts:

<%- flash.each do |key, msg| -%>
	<div id="<%= key %>">
		<p style="float:right;"><%= link_to_function 'X', "Effect.Fade('#{key}')" %></p>
		<p><%= msg %></p>
		<div class="clear"></div>
	</div>
<%- end -%>

This method will loop through each key in your flash hash and create a div with the name of the key, then put the contents inside with a link to close the message div.

I put this method in a partial called _notice_div.html.erb and include it at the top of my application layout. Here are the styles I use for notices and errors:

#notice { background-color: #A4E7A0; border: 1px solid #26722D; }
#error { background-color: #F0A8A8; border: 1px solid #900; }
#notice, #error { width: 90%; margin: 0 auto 10px auto; padding: 5px; }
#notice p, #error p { margin-left: 20px; padding: 0; font-size: .75em; color: #000; }
#notice a, #error a { text-decoration: none; padding: 0 3px; }
#notice a { border: 1px solid #26722D; color: #26722D; }
#error a { border: 1px solid #900; color: #900; }
#notice a:hover, #error a:hover { color: #333; border: 1px solid #333; }

This is a notice div.

This is an error div.

Routes Demystified

Sat, 02 Aug 2008 00:00:00 -0400

It took me a while to discover the full potential of Rails' routes. I slowly learned more and more neat stuff that made me like them more and more. They are extremely powerful and are very useful for URL re-writing. Following is all of my route knowledge. If you notice something that I didn't cover, please leave it in the comments.

A few basic routes:

# this will route domain.com/ to the index action of your main controller
map.connect '', :controller => 'main'

# this will create a custom URL for your about-us page
map.connect 'custom-url/about-us', :controller => 'about_us', :action => 'index'

Pay attention to the order of your routes in your routes.rb file. They are evaluated in order from top to bottom. Routes at the top will be used before routes at the bottom if they are too similar.

Named Routes

Instead of saying map.connect, let's get crazy and name our routes. I'll use the same routes as above and add a few.

# you can now call this route with home_path or home_url
map.home '', :controller => 'main'

# call this route with about_us_path or about_us_url
map.about_us 'custom-url/about-us', :controller => 'about_us', :action => 'index'

# symbols in the routes define options you pass when calling the route
# call product_details_path(:id => @product) to access this route
map.product_details 'products/detail-view/:id', :controller => 'products', :action => 'show'
# all-purpose route for the products controller : products_path(:action => 'search') or products_path(:action => 'buy', :id => product)
map.products 'products/:action/:id', :controller => 'products'

Route Blocks Using with_options

If we have several routes for the same controller, it makes sense to use with_options to simplify the definitions.

map.with_options :controller => 'news' do |m|
  m.news 'news-releases/list', :action => 'index' # news_path
  m.news_details 'news-releases/details/:id', :action => 'show' # news_details_path(:id => news_release)
  m.news_author 'news-releases/by-author/:name', :action => 'author' # news_author_path(:name => 'Bill')
end

Better URLs with Routes

Routes are great for creating search engine friendly URLs. Supposed you'd like to add the title of your blog post to the URL.

map.blog_details 'blog/details/:id/:name', :controller => 'blog', :action => 'show', :name => nil

Now you can call the blog_details path and give it the :id and :title as options for the URL. Also notice that I set :name => nil at the end of the route. This marks that option as optional for the route call.

# this call will generate the following URL: http://domain.com/blog/details/1/My-First-Blog-Post
# I'm using a helper method in this call entitled 'strip_chars', it is below
blog_details_path(:id => post, :title => strip_chars(post.title)) %>

# you can also omit the title when invoking the route because it is optional.
# since your 'details' method will be using the :id parameter to find the record
# we don't really need the title, it's just for search engines
blog_details_path(:id => post) %>

# this helper method takes a string, replaces all spaces with dashes, then strips out all non-letter, non-number, non-dashes
# it's good for generating URL-friendly titles
def strip_chars(string='')
  return '' if string.blank?
  string.gsub(' ','-').gsub(/[^a-z0-9\-]+/i, '')
end

Caching and Pagination

If we cache our site, and certain actions show a paginated list, then we need to add the :page attribute to the route to ensure that the cache is recorded properly. After all, to our server /blog/list looks the exact same as /blog/list?page=2 when retrieving cached pages.

map.blog 'blog/list/:page',
         :controller => 'blog',
         :action => 'list',
         :requirements => {:page => /\d+/},
         :page => nil
# blog_path
# blog_path(:page => 1)

Notice that we added something new, the :requirements option. For :page, it's a regular expression telling us the supplied value must be a number. I've also set :page => nil so that we don't always have to specify it when invoking the route.

One thing to watch out for when calling a paged route is to be careful when you're on another paged section of your site. Say I have the route above for blogs and a similar route for news releases. If I'm on the page /news/list/5 and I call blog_path it will take the :page parameter from the current URL and you'll end up on page 5 of your blog post list. Confused? Just make sure when you are calling a paged route to specify it as blog_path(:page => 1) to explicitly go to /blog/list/1 or call blog_path(:page => nil) to go to /blog/list. Both will work.

Route Conditions

Similar to RESTful routes, you can specify the method of the request with the :requirements option. While this is useful, it makes much more sense to just use map.resources to get real RESTful routes.

map.connect 'blog-post/:id', :controller => 'blog', :action => 'show', :requirements => { :method => :get }
map.connect 'blog-post/:id', :controller => 'blog', :action => 'update', :requirements => { :method => :post }

# a GET method to /blog-post/1 will route to the 'show' action
# a POST method to /blog-post/1 will route to the 'update' action

I think that's enough for normal routes. Hopefully soon I can write a post on RESTful routes, which are a whole different beast.

Rails Tips

Sun, 13 Jul 2008 00:00:00 -0400

While there are no shortages of posts listing tips for Rails, or lesser-known Ruby methods, I decided to write this post because these are shortcuts or helpers that I didn't know about until fairly recently. I'm going to try and update this post as I discover new railties and rubyisms along the way, so check back every now and then.

Symbol#to_proc

This is really a Ruby method, but it makes running a collect or map on ActiveRecord objects much easier. Whereas before, you would do this:

@members = Member.find(:all).map { |member| member.name }

Now, you can simplify it to this:

@members = Member.find(:all).map(&:name)

Model Calculations

This will let you do simple calculations on any ActiveRecord model (as long as the field you're calculating is numeric).

Student.average(:grade) # finds the average grade for all students (returns a float)
Student.maximum(:grade) # finds the highest grade
Student.minimum(:grade) # finds the lowest grade
Student.sum(:grade) # the sum of all grades

Custom ActiveRecord Associations

Let's say you have a model called BlogPost and one called Comment. A blog post has many comments, but you also have a boolean field on comments called approved that signifies if it's been decided that the comment is not spam (like most comments are). This is what your BlogPost model might look like:

class BlogPost < ActiveRecord::Base
  has_many :comments
end

You can add custom associations for approved_comments and unapproved_comments to your model to make fetching these comments a lot easier.

class BlogPost < ActiveRecord::Base
  has_many :comments
  has_many :approved_comments, :class_name => 'Comment', :conditions => 'approved=1'
  has_many :unapproved_comments, :class_name => 'Comment', :conditions => 'approved=0'
end

All you have to do is specify the class name of the associated model and the conditions of the find. This makes it possible to easily access these associations from within your views.

You can now show the number of approved comments for each post.

<%= @blog_post.title %> - <%= @blog_post.approved_comments.count %> Comments

You can also easily list out the approved comments.

<%- @blog_post.approved_comments.each do |comment| -%>
  <%= comment.author %> said:
  <%= comment.content %>
<%- end -%>

UPDATE: Shawn reminded me this week about named_scope, which was added in Rails 2.1. It makes custom associations a bit easier and more full-featured. You can get the same approved and non-approved comments with named_scope:

class Comment < ActiveRecord::Base
  belongs_to :blog_post
  named_scope :approved, :conditions => ["approved = ?", true]
  named_scope :unapproved, :conditions => ["approved = ?", false]
end

Notice that now the named_scope declarations go in the Comment model instead of the BlogPost model like the custom associations. You get the approved comments for a post with this line:

<%= blog_post.comments.approved %>

You can also combine named_scope calls when selecting records. Suppose our Comment model now has a named_scope for both approved and unapproved comments, as well as comments made by anonymous authors.

class Comment < ActiveRecord::Base
  belongs_to :post
  named_scope :approved, :conditions => ["approved = ?", true]
  named_scope :unapproved, :conditions => ["approved = ?", false]
  named_scope :anonymous, :conditions => ["name = ?", 'Anonymous']
end

You can use this to find all of the approved comments for a post where the author is 'Anonymous'.

<%= blog_post.comments.approved.anonymous %>

To add even more functionality to named_scope, you can add conditions to the call on the fly.

<%= post.comments.approved.all(:conditions => ["created_at > ?", 2.weeks.ago]) %>

This will pass the additional date condition to the find, making it possible to refine your searches even more.

Render Partial with Collection/Object

This is how I've always done my partials.

The view (index.html.erb):

<%- @posts.each do |post| -%>
  <%= render :partial => 'post', :locals => {:post => post} %>
<%- end -%>

The partial (_post.html.erb):

<%= post.title %> written by <%= post.author %>

I can simplify the call to the partial down to only one line of code (the partial itself will stay the same).

<div id="all_posts">
  <%= render :partial => 'post', :collection => @posts %>
</div>

By specifying the collection option, the view will call the partial post for each item in the @posts array.

But, let's say I wanted to call the partial for only one post. The old way:

<div id="single_post">
  <%= render :partial => 'post', :locals => {:post => @post} %>
</div>

Not terrible, but we can make it easier with the object option.

<div id="single_post">
  <%= render :partial => 'post', :object => @post %>
</div>

This will call the partial, and pass it only the object that we specify. Shorter and cleaner.

RJS with link_to_function

If you have several things on your page that need to be updated, and you want to do it with a javascript call instead of an AJAX call to the server, you can do it by passing a block to the link_to_function method.

Suppose this is my view:

<div id="list">
  <p id="list_title"><%= @list.title %></p>
  <div id="list_items">
    <%= render :partial => 'item', :collection => @list.items %>
  </div>
  <%= link_to_function 'Change it up' do |page|
    page.replace_html 'list_items', 'New Item Title'
    page.hide 'list_items'
  end %>
</div>

This is a poor example, but hopefully you can see what I'm trying to illustrate here.

Simplified FIND in Rails 2.1

With the release of Rails 2.1, they've added some much-needed find methods for easily getting all, first and last records for a model.

@all_posts = Post.all
@first_post = Post.first
@last_post = Post.last

And, of course, you can pass conditions and order options to the new find methods.

@all_posts = Post.all(:order => :updated_at)
@first_post = Post.first(:conditions => ["title LIKE ?", '%Rails%'])
@last_post = Post.last(:order => 'created_at DESC')

Site Rewrite

Sun, 08 Jun 2008 00:00:00 -0400

I've been really lazy about updating the blog lately. I'd like to say that I've been busy working on some cool new project, but the reality is that I bought a PS3 a few months ago, and all of my free time has been taken up by Call of Duty 4 and Grand Theft Auto. By the way, if you're on PSN, send me a friend request (deadwards).

To try and force myself to get back into the blog, I decided to re-write it since Rails 2.1 was recently released. It was really funny looking at some of my old code (keep in mind, I originally wrote this blog as my first foray into Rails, circa May 06). All of the code has at least been refactored, and in many cases totally re-written. I've also added caching where I can to increase the speed a bit. Hopefully, this will be the kick in the ass I need to get back to blogging.

ps I finally broke down and created a Twitter account.

HTTP GET and POST requests with Ruby

Wed, 07 Nov 2007 00:00:00 -0500

A while ago, I was working on a project for a client that used a third-party newsletter generator for capturing and storing email addresses. To add an email address, the application spits out some code for a form that you can put on your site. A user supplies his name and email address, then submits the form and it gets stored within the third-party app's database.

The problem arose when they wanted to automatically subscribe not only people who requested subscriptions, but also everyone who used the online contact form AND anyone who used the 'email to a friend' feature on one of the interior pages. Obvious misgivings aside, I set out to do what I was told (like any good drone).

The problem was, I needed to do a POST request to subscribe the person to the third-party app, but I couldn't do that with a regular form because I was already posting to the actual action being invoked. Luckily, Ruby has a built in Net::HTTP class for generating GET and POST requests from within the code.

Here is the method I needed to add the POST request to:

def email_to_friend
  ...other code...
  # now, do the dirty work
  require 'net/http'
  # get the url that we need to post to
  url = URI.parse('http://www.url.com/subscribe')
  # build the params string
  post_args1 = { 'email' => params[:email] }
  # send the request
  resp, data = Net::HTTP.post_form(url, post_args1)
end

The post_form method returns a Net::HTTPResponse object and an entity body string (in Ruby 1.8, it only returns the Net::HTTPResponse object). You can also use the post method.

Similarly, you can perform a GET request on a URL like so:

require 'net/http'
result = Net::HTTP.get(URI.parse('http://www.site.com/about.html'))
# or
result = Net::HTTP.get(URI.parse('http://www.site.com'), '/about.html')

The get method returns a String.

That's simple enough, right?

Adding multiple email attachments with Ruby on Rails

Wed, 20 Jun 2007 00:00:00 -0400

I was building some forms for a client that required the user be able to upload supporting documents along with the application. I had implemented emailable forms before with single attachments, but never multiple. Turns out, it was just as simple to do, I just needed to call the attach function for each file I wanted to attach.

Here is the method in my controller that calls the ActionMailer class to send the email, where params[:file1], params[:file2], and params[:file3] are the file_field_tag's from the form:

UPDATE: I've re-factored this after Shawn suggested that it could be simplified into an array and iterated over.

def submit_application
  @uploaded_files = []
  @uploaded_files << params[:file1]
  @uploaded_files << params[:file2]
  @uploaded_files << params[:file3]
  ContactMailer.deliver_email_with_attachments(params[:application], @uploaded_files)
  flash[:notice] = 'Your application has been submitted.  Thank you!'
  redirect_to application_home_url
rescue Exception => ex
  logger.warn(ex.message)
  flash[:notice] = 'Uh oh!  There was an error sending your application.'
  redirect_to :back
end

And here is the ActionMailer method that attaches the files. I just need to iterate over the files, calling attach for each one.

def email_with_attachments(application_fields={},files=[])
  @headers = {}
  @sent_on = Time.now
  @recipients = 'client@domain.com'
  @from = 'info@domain.com'

  @subject = 'Here are some file attachments'
  application_fields.keys.each {|k| @body[k] = fields[k]}

  # attach files
  files.each do |file|
    attachment "application/octet-stream" do |a|
      a.body = file.read
      a.filename = file.original_filename
    end unless file.blank?
  end
end

The "application/octet-stream" is the generic MIME type for attaching unknown file types.

Pretty simple!

Parsing an RSS feed with Ruby

Sat, 09 Jun 2007 00:00:00 -0400

Parsing an RSS feed is insanely simple with Ruby. Two lines is all it takes. . .

require 'rss'
rss = RSS::Parser.parse(open('http://www.travisonrails.com/feed/posts').read, false)

Now you'll have an Array of the results, so you can do something like:

rss.items.each { |i| puts "#{i.title} - #{i.date}" }

Generate random text with Ruby

Thu, 07 Jun 2007 00:00:00 -0400

UPDATE: Changed the generate_password method slightly based on commenter Dave Burt's suggestion.

I'm working on a project where the user can reset their password if they've forgotten it. So, I need to generate a random password and email it to them so they can login and change it. Fortunately, I found this neat little Ruby snippet that will generate random text of a given length:

def generate_password(length=6)
  chars = 'abcdefghjkmnpqrstuvwxyzABCDEFGHJKLMNOPQRSTUVWXYZ23456789'
  password = ''
  length.times { |i| password << chars[rand(chars.length)] }
  password
end

Some examples:

generate_password
>> U48ydn

generate_password(10)
>> QzWXdAkDy5

Rails inline ERb effects on HTML structure

Sat, 31 Mar 2007 00:00:00 -0400

When using Ruby on Rails, ERb (embedded Ruby) is used a LOT in the X/HTML. There are two types of ERb,

An evaluation block:

<% some_code %>

And an output block:

<%= @print_this_variable %>

These blocks are necessary when using Rails, and I've noticed that when I do a 'View Source' (via the Web Developer addon for Firefox, of course), I see a lot of funky spacing and line breaking where the ERb's have been evaluated. Probably fine for most people, but it makes reading the outputted HTML code a hassle.

It turns out that there are really three ways to use the evaluation ERb that can affect your spacing and line-breaking.

Firstly, the output block is used just like you'd expect to use it. If your code says this:

<p>
  Text before ERb.
  <%= "code_goes_here" %>
  Text after ERb
</p>

The resulting HTML will look just like this:

<p>
  Text before ERb.
  code_goes_here
  Text after ERb
</p>

Evaluation block use #1: If you just put a block, it will cause a line break after the block in the HTML, so if you had this in your code:

<p>
  Text before ERb.
  <% some_code %>
  Text after ERb
</p>

The resulting HTML code would look like this:

<p>
  Text before ERb.

  Text after ERb
</p>

Evaluation block use #2: If you add a dash(-) at the end of the block, it will prevent it from adding a line break. So, if your code looks like this:

<p>
  Text before ERb.
  <% some_code -%>
  Text after ERb
</p>

The resulting HTML code would look like this:

<p>
  Text before ERb.
    Text after ERb
</p>

The line break is gone, but the space taken by the block is still there. That leads us to. . .

Evaluation block use #3: If you add a dash(-) at the beginning AND end of the block, it will prevent it from adding a line break AND remove the leading space it would have taken up. So, if your code looks like this:

<p>
  Text before ERb.
  <%- some_code -%>
  Text after ERb
</p>

The resulting HTML code would look like this:

<p>
  Text before ERb.
  Text after ERb
</p>

You'd never know there was a code block there! Is this useful? I don't know... maybe.

Rails eager loading of associations

Sun, 18 Feb 2007 00:00:00 -0500

I ran into an interesting problem with table associations at work the other day. Below is a simple data model of the tables I was working with. Basically, here's how it breaks down: A user is part of any given group (but only one group per user). A document (any type) can be uploaded and assigned to a folder. A group is used to assign viewing privileges to each document, so that every user in the group can see the document. See below:

The problem came up because once a user is logged in, I need to get all of the folders that contain documents that the user's group has permission to see (a folder could contain documents not viewable by the group). I spent a few minutes scratching my head on how best to do a find to get the results I needed. I really couldn't come up with anything that would work.

So, of course, when this happens, I do a little leg-stretching and walk over to Adam and Shawn's space to ask them how they would do it. After explaining the situation and a little white board art, they reminded me of eager loading of associations (which I've never really had to use).

By using the :include option in my find method call, I can pre-load table associations to make my complex query a lot easier. My code ended up looking like this:

# find the logged-in user
user = User.find(session[:intranet_user])
# get all of the folders that contain documents they have access to
@folders = Folder.find(:all, :include => {:documents => {:groups => :users}}, :conditions => "users.id = #{user.id}" )

This worked perfectly!

A note about eager loading of associations: they can save a lot of resources when used correctly. Say you have a table called books and a table called authors, and each book has one author. To get all of the books for display, you might put:

@books = Book.find(:all)

Then, in your page, you might have:

<% for book in @books -%>
	Title: <%= book.title %>
	Written by: <%= book.author.name %>
<% end -%>

Not only do you run a SQL query to get all of the books, you then run an additional query for each book to find it's author. You can simplify this down to only one query, by using eager loading, like so:

@books = Book.find(:all, :include => :author)

This pre-loads all of the data with only one SQL query.