Class: ActionController::Base

Action Controllers are the core of a web request in Rails. They are made up of one or more actions that are executed on request and then either render a template or redirect to another action. An action is defined as a public method on the controller, which will automatically be made accessible to the web-server through Rails Routes.

A sample controller could look like this:

  class GuestBookController < ActionController::Base
    def index
      @entries = Entry.find(:all)
    end

    def sign
      Entry.create(params[:entry])
      redirect_to :action => "index"
    end
  end

Actions, by default, render a template in the app/views directory corresponding to the name of the controller and action after executing code in the action. For example, the index action of the GuestBookController would render the template app/views/guestbook/index.erb by default after populating the @entries instance variable.

Unlike index, the sign action will not render a template. After performing its main purpose (creating a new entry in the guest book), it initiates a redirect instead. This redirect works by returning an external "302 Moved" HTTP response that takes the user to the index action.

The index and sign represent the two basic action archetypes used in Action Controllers. Get-and-show and do-and-redirect. Most actions are variations of these themes.

Requests

Requests are processed by the Action Controller framework by extracting the value of the "action" key in the request parameters. This value should hold the name of the action to be performed. Once the action has been identified, the remaining request parameters, the session (if one is available), and the full request with all the http headers are made available to the action through instance variables. Then the action is performed.

The full request object is available with the request accessor and is primarily used to query for http headers. These queries are made by accessing the environment hash, like this:

  def server_ip
    location = request.env["SERVER_ADDR"]
    render :text => "This server hosted at #{location}"
  end

Parameters

All request parameters, whether they come from a GET or POST request, or from the URL, are available through the params method which returns a hash. For example, an action that was performed through /weblog/list?category=All&limit=5 will include { "category" => "All", "limit" => 5 } in params.

It’s also possible to construct multi-dimensional parameter hashes by specifying keys using brackets, such as:

  <input type="text" name="post[name]" value="david">
  <input type="text" name="post[address]" value="hyacintvej">

A request stemming from a form holding these inputs will include { "post" => { "name" => "david", "address" => "hyacintvej" } }. If the address input had been named "post[address][street]", the params would have included { "post" => { "address" => { "street" => "hyacintvej" } } }. There’s no limit to the depth of the nesting.

Sessions

Sessions allows you to store objects in between requests. This is useful for objects that are not yet ready to be persisted, such as a Signup object constructed in a multi-paged process, or objects that don’t change much and are needed all the time, such as a User object for a system that requires login. The session should not be used, however, as a cache for objects where it’s likely they could be changed unknowingly. It’s usually too much work to keep it all synchronized — something databases already excel at.

You can place objects in the session by using the session method, which accesses a hash:

  session[:person] = Person.authenticate(user_name, password)

And retrieved again through the same hash:

  Hello #{session[:person]}

For removing objects from the session, you can either assign a single key to nil, like session[:person] = nil, or you can remove the entire session with reset_session.

By default, sessions are stored on the file system in RAILS_ROOT/tmp/sessions. Any object can be placed in the session (as long as it can be Marshalled). But remember that 1000 active sessions each storing a 50kb object could lead to a 50MB store on the filesystem. In other words, think carefully about size and caching before resorting to the use of the session on the filesystem.

An alternative to storing sessions on disk is to use ActiveRecordStore to store sessions in your database, which can solve problems caused by storing sessions in the file system and may speed up your application. To use ActiveRecordStore, uncomment the line:

  config.action_controller.session_store = :active_record_store

in your environment.rb and run rake db:sessions:create.

Responses

Each action results in a response, which holds the headers and document to be sent to the user’s browser. The actual response object is generated automatically through the use of renders and redirects and requires no user intervention.

Renders

Action Controller sends content to the user by using one of five rendering methods. The most versatile and common is the rendering of a template. Included in the Action Pack is the Action View, which enables rendering of ERb templates. It’s automatically configured. The controller passes objects to the view by assigning instance variables:

  def show
    @post = Post.find(params[:id])
  end

Which are then automatically available to the view:

  Title: <%= @post.title %>

You don’t have to rely on the automated rendering. Especially actions that could result in the rendering of different templates will use the manual rendering methods:

  def search
    @results = Search.find(params[:query])
    case @results
      when 0 then render :action => "no_results"
      when 1 then render :action => "show"
      when 2..10 then render :action => "show_many"
    end
  end

Read more about writing ERb and Builder templates in classes/ActionView/Base.html.

Redirects

Redirects are used to move from one action to another. For example, after a create action, which stores a blog entry to a database, we might like to show the user the new entry. Because we’re following good DRY principles (Don‘t Repeat Yourself), we’re going to reuse (and redirect to) a show action that we’ll assume has already been created. The code might look like this:

  def create
    @entry = Entry.new(params[:entry])
    if @entry.save
      # The entry was saved correctly, redirect to show
      redirect_to :action => 'show', :id => @entry.id
    else
      # things didn't go so well, do something else
    end
  end

In this case, after saving our new entry to the database, the user is redirected to the show method which is then executed.

Calling multiple redirects or renders

An action should conclude with a single render or redirect. Attempting to try to do either again will result in a DoubleRenderError:

  def do_something
    redirect_to :action => "elsewhere"
    render :action => "overthere" # raises DoubleRenderError
  end

If you need to redirect on the condition of something, then be sure to add "and return" to halt execution.

  def do_something
    redirect_to(:action => "elsewhere") and return if monkeys.nil?
    render :action => "overthere" # won't be called unless monkeys is nil
  end

Methods

action_methods action_methods add_class_variables_to_assigns add_instance_variables_to_assigns add_variables_to_assigns append_view_path assert_existence_of_template_file assign_default_content_type_and_charset assign_names assign_shortcuts close_session complete_request_uri controller_class_name controller_class_name controller_name controller_name controller_path controller_path default_template_name default_url_options exempt_from_layout expires_in expires_now filter_parameter_logging forget_variables_added_to_assigns head hidden_actions hide_action initialize_current_url initialize_template_class log_processing perform_action performed? prepend_view_path process_cgi process_cleanup process_test process_with_test protected_instance_variables redirect_to render render_to_string request_origin reset_session reset_variables_added_to_assigns sending_file? session_enabled? strip_out_controller template_exempt_from_layout? template_exists? template_path_includes_controller? template_public? url_for view_paths view_paths view_paths=

Constants

DEFAULT_RENDER_STATUS_CODE = "200 OK"

Attributes

action_name	[RW]	Returns the name of the action this controller is processing.
assigns	[RW]	Holds the hash of variables that are passed on to the template class to be made available to the view. This hash is generated by taking a snapshot of all the instance variables in the current scope just before a template is rendered.

Public Class methods

append_view_path(path)

Adds a view_path to the end of the view_paths array. If the current class has no view paths, copy them from the superclass

Requests

Parameters

Sessions

Responses

Renders

Redirects

Calling multiple redirects or renders

Methods

Included Modules

Constants

Attributes

Public Class methods

Private Class methods

Public Instance methods

Protected Instance methods

Rendering an action

Rendering partials

Automatic etagging

Rendering a template

Rendering a file

Rendering text

Rendering JSON

Rendering an inline template

Rendering inline JavaScriptGenerator page updates

Rendering with status and location headers

Private Instance methods