Ruby Saved My Life

There is this helpful method I've been evolving in my apps for a bit, it's called render_either and it goes a little something like this: (in application.rb)

 
  def render_either(opts = {})
    # For MIME:Type Recognition
    # respond_to do |f|
    #   f.js {@wants = :js}
    #   f.xml {@wants = :xml}
    #   f.html {@wants = :html}
    # end
    # Then use @wants
    if request.xhr?
      if opts[:ajax]
        if opts[:ajax][:json]
          render :json => opts[:ajax][:json].to_json
        else
          render opts[:ajax]
        end
      end
    elsif params[:bookmarklet]
      if opts[:bookmarklet]
        if opts[:bookmarklet][:redirect_to]
          redirect_to opts[:bookmarklet][:redirect_to]
        else
          render opts[:bookmarklet]
        end
      end
    else
      if opts[:default]
        if opts[:default][:redirect]
          redirect_to opts[:default][:redirect]
        else
          render opts[:default]
        end
      end
    end
    return false
  end
 

This method is very much incomplete - I mean it works - but I want to take it further (and make it prettier and more condensed, but for now, sadly, that's actually more readable to me while I improve it). So why did I write it, what does it do, and why should you care? Let's say you want to be able to create a Post from a vanilla form, from a lightbox (or an ajax form), and from a bookmarklet. Obviously, you want this all occurring in a PostsController within the new and create methods. Here this is without render_either

 
PostsController < ApplicationController
 
  # For a vanilla form new.rhtml should be rendered with layout application (default)
  # For a bookmarklet, render new.rhtml but with layout bookmarklet
  # For a lightbox, send back new.rhtml without a layout (so that it back be loaded into a lightbox easily)
  def new
    @post ||= Post.new
    if request.xhr?
      render :layout => false
      return false # To prevent DoubleRenderError
    elsif params[:bookmarklet] #indicating that this is being loaded in a bookmarklet
      render :layout => "bookmarklet"
      return false
    end
  end
 
  # For a vanilla form, if post is valid, redirect_to post_path(@post),
  # else, render :action => "new"
  # For a lightbox, if post is valid, render :partial => "post",
  # else, render :action => "new" without layout
  # For a bookmarklet, if post is valid, redirect_to close_bookmarklet_path,
  # else, render :action => "new", :layout => "bookmarklet"
  def create
    @post = Post.new(params[:post])
    if @post.save
      if request.xhr?
        render :partial => "post"
        return false
      elsif params[:bookmarklet]
        redirect_to close_bookmarklet_path
        return false
      else
        redirect_to post_path
        return false
      end
    else
      if request.xhr?
        render :action => "new", :layout => false
        return false
      elsif params[:bookmarklet]
        render :action => "new", :layout => "bookmarklet"
        return false
      else
        render :action => "new"
        return false
      end
    end
  end
 
end
 

Ow, that's painful, right? And that doesn't even deal with some of the added complexities in a real application (returning json, returning xml for api calls, other branches and conditions). The render_either method.

 
PostsController < ApplicationController
 
  # For a vanilla form new.rhtml should be rendered with layout application (default)
  # For a bookmarklet, render new.rhtml but with layout bookmarklet
  # For a lightbox, send back new.rhtml without a layout (so that it back be loaded into a lightbox easily)
  def new
    @post ||= Post.new
    render_either :ajax => {:layout => false},
                  :bookmarklet => {:layout => "bookmarklet"},
  end
 
  # For a vanilla form, if post is valid, redirect_to post_path(@post),
  # else, render :action => "new"
  # For a lightbox, if post is valid, render :partial => "post",
  # else, render :action => "new" without layout
  # For a bookmarklet, if post is valid, redirect_to close_bookmarklet_path,
  # else, render :action => "new", :layout => "bookmarklet"
  def create
    @post = Post.new(params[:post])
    if @post.save
      render_either :ajax => {:partial => "post"},
                    :bookmarklet => {:redirect_to => close_bookmarklet_path},
                    :default => {:redirect_to => post_path(@post)}
    else
      render_either :ajax => {:action => "new", :layout => false},
                    :bookmarklet => {:action => "new", :layout => "bookmarklet"}
                    :default => {:action => "new"}
    end
  end
end
 

That's the point of render_either, in a nutshell, to abstract out display logic from a controller. This is one of the most basic arguments for render_either, and the reason I created it. I wanted to DRY the logic and remove less if / else branches in a controller action. It then began growing into a stronger package that allows me to do some awesome things with xml and json that I will touch on in later posts. Let's just say that set_flash loves render_either. Any questions?

You're just starting on rails and you're very excited about the ease of flash[:notice]. But every now and then, you set a flash notice and it seems to follow your clicks to the next action when it shouldn't. Why? I'll tell you.

Intro to flash[:notice]

flash[:notice] belongs to FlashHash.The basic use of the flash hash is flash[:notice], a place to put a message that describes the result of an action in a rails app. Let's look at an example:

 
class WeblogController < ActionController::Base
  def create
    @post = Post.new(params[:post])
    if @post.save
      flash[:notice] = "#{@post.title} has been created."
    else
      flash[:notice]= "#{@post.title} could not be created."
    end
  end
end
 

Pretty self explanatory. However, things get a bit complicated when you think about what that method should be doing. If the post is successfully created, the method should redirect_to post_path(@post), else, render :action => "new". The new action will fill the form in using the already initialized @post object (and it's errors) and the flash message will let them know that there was a problem. So let's add that in real quick:

 
class WeblogController < ActionController::Base
  def create
    @post = Post.new(params[:post])
    if @post.save
      flash[:notice] = "#{@post.title} has been created."
      redirect_to post_path(@post)
    else
      flash[:notice]= "#{@post.title} could not be created."
      render :action => "new"
    end
  end
end
 

Now flash[:notice] becomes a problem. When the user sees there was an error creating the post, he decided to abandon the process and move onto a different page in your application. Well, what's going to happen is that on the next page, he is going to see the same flash[:notice] he just saw notifying him of the error.

Flash Right Now

The Flash hash by default persists to the next action. That's what it's suppose to do - it's a way to send a message to the next action. However, in our create post example, if the post fails creation, there is no next action, rather, the create action simply renders the new action, a very common pattern. That's why when the user moves to another page, the flash[:notice] persists, because that other page is the next action. Obviously, you want to avoid that, and that's exactly what flash.now is for:

 
class WeblogController < ActionController::Base
  def create
    @post = Post.new(params[:post])
    if @post.save
      flash[:notice] = "#{@post.title} has been created."
      redirect_to post_path(@post)
    else
      flash.now[:notice]= "#{@post.title} could not be created."
      render :action => "new"
    end
  end
end
 

A basic rule to know when to use flash[:notice] and when to use flash.now[:notice] is if the action is redirecting - redirect_to - use flash[:notice], if it's rendering - render :action - use flash.now[:notice]. This is really just the beginning of the power of the flash object. Stay tuned for some more posts on how to really make use of this great feature in rails.