Action Controllers are made up of one or more actions that performs its purpose and then either renders a template or redirects 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 a mod_rewrite mapping. 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 GuestBookController.template_root = "templates/" GuestBookController.process_cgi
All actions assume that you want to render a template matching the name of the action at the end of the performance unless you tell it otherwise. The index action complies with this assumption, so after populating the @entries instance variable, the GuestBookController will render "templates/guestbook/index.rhtml".
Unlike index, the sign action isn’t interested in rendering a template. So after performing its main purpose (creating a new entry in the guest book), it sheds the rendering assumption and 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.
Also note that it’s the final call to process_cgi that actually initiates the action performance. It will extract request and response objects from the CGI
When Action Pack is used inside of Rails, the template_root is automatically configured and you don’t need to call process_cgi yourself.
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 hello_ip location = request.env["REMOTE_IP"] render_text "Hello stranger from #{location}" end
All request parameters whether they come from a GET or POST request, or from the URL, are available through the params hash. So 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 allows you to store objects in memory 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 hash accessor:
session[:person] = Person.authenticate(user_name, password)
And retrieved again through the same hash:
Hello #{session[:person]}
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 memory overhead. In other words, think carefully about size and caching before resorting to the use of the session.
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.
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, so it’s normally nothing you’ll need to be concerned about.
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.
Redirecting is what actions that update the model do when they’re done. The save_post method shouldn’t be responsible for also showing the post once it’s saved — that’s the job for show_post. So once save_post has completed its business, it’ll redirect to show_post. All redirects are external, which means that when the user refreshes his browser, it’s not going to save the post again, but rather just show it one more time.
This sounds fairly simple, but the redirection is complicated by the quest for a phenomenon known as "pretty urls". Instead of accepting the dreadful beings that is "weblog_controller?action=show&post_id=5", Action Controller goes out of its way to represent the former as "/weblog/show/5". And this is even the simple case. As an example of a more advanced pretty url consider "/library/books/ISBN/0743536703/show", which can be mapped to books_controller?action=show&type=ISBN&id=0743536703.
Redirects work by rewriting the URL of the current action. So if the show action was called by "/library/books/ISBN/0743536703/show", we can redirect to an edit action simply by doing redirect_to(:action => "edit"), which could throw the user to "/library/books/ISBN/0743536703/edit". Naturally, you’ll need to setup the routes configuration file to point to the proper controller and action in the first place, but once you have, it can be rewritten with ease.
Let’s consider a bunch of examples on how to go from "/clients/37signals/basecamp/project/dash" to somewhere else:
redirect_to(:action => "edit") => /clients/37signals/basecamp/project/dash redirect_to(:client_name => "nextangle", :project_name => "rails") => /clients/nextangle/rails/project/dash
Those redirects happen under the configuration of:
map.connect 'clients/:client_name/:project_name/:controller/:action'
An action should conclude by 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 # == Environments
Action Controller works out of the box with CGI, FastCGI, and mod_ruby. CGI and mod_ruby controllers are triggered just the same using:
WeblogController.process_cgi
FastCGI controllers are triggered using:
FCGI.each_cgi{ |cgi| WeblogController.process_cgi(cgi) }
DEFAULT_RENDER_STATUS_CODE | = | "200 OK" |
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. |
headers | [RW] | Holds a hash of header names and values. Accessed like headers["Cache-Control"] to get the value of the Cache-Control directive. Values should always be specified as strings. |
params | [RW] | Holds a hash of all the GET, POST, and Url parameters passed to the action. Accessed like @params["post_id"] to get the post_id. No type casts are made, so all values are returned as strings. |
request | [RW] | Holds the request object that’s primarily used to get environment variables through access like request.env["REQUEST_URI"]. |
response | [RW] | Holds the response object that’s primarily used to set additional HTTP headers through access like response.headers["Cache-Control"] = "no-cache". Can also be used to access the final body HTML after a template has been rendered through response.body — useful for after_filters that wants to manipulate the output, such as a OutputCompressionFilter. |
session | [RW] | Holds a hash of objects in the session. Accessed like session[:person] to get the object tied to the "person" key. The session will hold any type of object as values, but the key should be a string. |
Converts the class name from something like "OneModule::TwoModule::NeatController" to "NeatController".
# File vendor/rails/actionpack/lib/action_controller/base.rb, line 292 292: def controller_class_name 293: @controller_class_name ||= name.demodulize 294: end
Converts the class name from something like "OneModule::TwoModule::NeatController" to "neat".
# File vendor/rails/actionpack/lib/action_controller/base.rb, line 297 297: def controller_name 298: @controller_name ||= controller_class_name.sub(/Controller$/, '').underscore 299: end
Convert the class name from something like "OneModule::TwoModule::NeatController" to "one_module/two_module/neat".
# File vendor/rails/actionpack/lib/action_controller/base.rb, line 302 302: def controller_path 303: unless @controller_path 304: components = self.name.to_s.split('::') 305: components[-1] = $1 if /^(.*)Controller$/ =~ components.last 306: # Accomodate the root Controllers module. 307: components.shift if components.first == 'Controllers' 308: @controller_path = components.map { |name| name.underscore }.join('/') 309: end 310: @controller_path 311: end
Return an array containing the names of public methods that have been marked hidden from the action processor. By default, all methods defined in ActionController::Base and included modules are hidden. More methods can be hidden using hide_actions.
# File vendor/rails/actionpack/lib/action_controller/base.rb, line 316 316: def hidden_actions 317: write_inheritable_attribute(:hidden_actions, ActionController::Base.public_instance_methods) unless read_inheritable_attribute(:hidden_actions) 318: read_inheritable_attribute(:hidden_actions) 319: end
Hide each of the given methods from being callable as actions.
# File vendor/rails/actionpack/lib/action_controller/base.rb, line 322 322: def hide_action(*names) 323: write_inheritable_attribute(:hidden_actions, hidden_actions | names.collect {|n| n.to_s}) 324: end
Process a request extracted from an CGI object and return a response. Pass false as session_options to disable sessions (large performance increase if sessions are not needed). The session_options are the same as for CGI::Session:
# File vendor/rails/actionpack/lib/action_controller/cgi_process.rb, line 30 30: def self.process_cgi(cgi = CGI.new, session_options = {}) 31: new.process_cgi(cgi, session_options) 32: end
Process a test request called with a TestRequest object.
# File vendor/rails/actionpack/lib/action_controller/test_process.rb, line 7 7: def self.process_test(request) 8: new.process_test(request) 9: end
Set the template root to be one directory behind the root dir of the controller. Examples:
/code/weblog/components/admin/users_controller.rb with Admin::UsersController will use /code/weblog/components as template root and find templates in /code/weblog/components/admin/users/ /code/weblog/components/admin/parties/users_controller.rb with Admin::Parties::UsersController will also use /code/weblog/components as template root and find templates in /code/weblog/components/admin/parties/users/
# File vendor/rails/actionpack/lib/action_controller/base.rb, line 334 334: def uses_component_template_root 335: path_of_calling_controller = File.dirname(caller[0].split(/:\d+:/).first) 336: path_of_controller_root = path_of_calling_controller.sub(/#{controller_path.split("/")[0..-2]}$/, "") # " (for ruby-mode) 337: self.template_root = path_of_controller_root 338: end
Converts the class name from something like "OneModule::TwoModule::NeatController" to "NeatController".
# File vendor/rails/actionpack/lib/action_controller/base.rb, line 445 445: def controller_class_name 446: self.class.controller_class_name 447: end
Converts the class name from something like "OneModule::TwoModule::NeatController" to "neat".
# File vendor/rails/actionpack/lib/action_controller/base.rb, line 450 450: def controller_name 451: self.class.controller_name 452: end
Returns a URL that has been rewritten according to the options hash and the defined Routes. (For doing a complete redirect, use redirect_to). url_for is used to: All keys given to url_for are forwarded to the Route module save for the following:
The URL is generated from the remaining keys in the hash. A URL contains two key parts: the <base> and a query string. Routes composes a query string as the key/value pairs not included in the <base>.
The default Routes setup supports a typical Rails path of "controller/action/id" where action and id are optional, with action defaulting to ‘index’ when not given. Here are some typical url_for statements and their corresponding URLs:
url_for :controller => 'posts', :action => 'recent' # => 'proto://host.com/posts/recent' url_for :controller => 'posts', :action => 'index' # => 'proto://host.com/posts' url_for :controller => 'posts', :action => 'show', :id => 10 # => 'proto://host.com/posts/show/10'
When generating a new URL, missing values may be filled in from the current request’s parameters. For example, url_for :action => ‘some_action‘ will retain the current controller, as expected. This behavior extends to other parameters, including :controller, :id, and any other parameters that are placed into a Route’s path. The URL helpers such as url_for have a limited form of memory: when generating a new URL, they can look for missing values in the current request’s parameters. Routes attempts to guess when a value should and should not be taken from the defaults. There are a few simple rules on how this is performed:
The final rule is applied while the URL is being generated and is best illustrated by an example. Let us consider the route given by map.connect ‘people/:last/:first/:action’, :action => ‘bio’, :controller => ‘people’.
Suppose that the current URL is "people/hh/david/contacts". Let’s consider a few different cases URLs which are generated from this page.
last components, and the action shall change. The generated URL will be, "people/hh/david/bio".
However, you might ask why the action from the current request, ‘contacts’, isn’t carried over into the new URL. The answer has to do with the order in which the parameters appear in the generated path. In a nutshell, since the value that appears in the slot for :first is not equal to default value for :first we stop using defaults. On it’s own, this rule can account for much of the typical Rails URL behavior. Although a convienence, defaults can occasionaly get in your way. In some cases a default persists longer than desired. The default may be cleared by adding :name => nil to url_for’s options. This is often required when writing form helpers, since the defaults in play may vary greatly depending upon where the helper is used from. The following line will redirect to PostController’s default action, regardless of the page it is displayed on:
url_for :controller => 'posts', :action => nil
Instead of passing an options hash, you can also pass a method reference in the form of a symbol. Consider this example:
class WeblogController < ActionController::Base def update # do some update redirect_to :dashboard_url end protected def dashboard_url url_for :controller => (@project.active? ? "project" : "account"), :action => "dashboard" end end
# File vendor/rails/actionpack/lib/action_controller/base.rb, line 436 436: def url_for(options = {}, *parameters_for_method_reference) #:doc: 437: case options 438: when String then options 439: when Symbol then send(options, *parameters_for_method_reference) 440: when Hash then @url.rewrite(rewrite_options(options)) 441: end 442: end
Overwrite to implement a number of default options that all url_for-based methods will use. The default options should come in the form of a hash, just like the one you would use for url_for directly. Example:
def default_url_options(options) { :project => @project.active? ? @project.url_name : "unknown" } end
As you can infer from the example, this is mostly useful for situations where you want to centralize dynamic decisions about the urls as they stem from the business domain. Please note that any individual url_for call can always override the defaults set by this method.
# File vendor/rails/actionpack/lib/action_controller/base.rb, line 677 677: def default_url_options(options) #:doc: 678: end
Redirects the browser to the target specified in options. This parameter can take one of three forms:
Examples:
redirect_to :action => "show", :id => 5 redirect_to "http://www.rubyonrails.org" redirect_to "/images/screenshot.jpg"
The redirection happens as a "302 Moved" header.
# File vendor/rails/actionpack/lib/action_controller/base.rb, line 692 692: def redirect_to(options = {}, *parameters_for_method_reference) #:doc: 693: case options 694: when %r{^\w+://.*} 695: raise DoubleRenderError if performed? 696: logger.info("Redirected to #{options}") unless logger.nil? 697: response.redirect(options) 698: response.redirected_to = options 699: @performed_redirect = true 700: 701: when String 702: redirect_to(request.protocol + request.host_with_port + options) 703: 704: else 705: if parameters_for_method_reference.empty? 706: redirect_to(url_for(options)) 707: response.redirected_to = options 708: else 709: redirect_to(url_for(options, *parameters_for_method_reference)) 710: response.redirected_to, response.redirected_to_method_params = options, parameters_for_method_reference 711: end 712: end 713: end
Renders the content that’ll be returned to the browser as the response body. This can just be as regular text, but is more often the compilation of a template.
Action rendering is the most common form and the type used automatically by Action Controller when nothing else is specified. By default, actions are rendered within the current layout (if one exists).
# Renders the template for the action "goal" within the current controller render :action => "goal" # Renders the template for the action "short_goal" within the current controller, # but without the current active layout render :action => "short_goal", :layout => false # Renders the template for the action "long_goal" within the current controller, # but with a custom layout render :action => "short_goal", :layout => "spectacular"
Deprecation notice: This used to have the signatures render_action("action", status = 200), render_without_layout("controller/action", status = 200), and render_with_layout("controller/action", status = 200, layout).
Partial rendering is most commonly used together with Ajax calls that only updates one or a few elements on a page without reloading. Rendering of partials from the controller makes it possible to use the same partial template in both the full-page rendering (by calling it from within the template) and when sub-page updates happen (from the controller action responding to Ajax calls). By default, the current layout is not used.
# Renders the partial located at app/views/controller/_win.r(html|xml) render :partial => "win" # Renders the partial with a status code of 500 (internal error) render :partial => "broken", :status => 500 # Renders the same partial but also makes a local variable available to it render :partial => "win", :locals => { :name => "david" } # Renders a collection of the same partial by making each element of @wins available through # the local variable "win" as it builds the complete response render :partial => "win", :collection => @wins # Renders the same collection of partials, but also renders the win_divider partial in between # each win partial. render :partial => "win", :collection => @wins, :spacer_template => "win_divider"
Deprecation notice: This used to have the signatures render_partial(partial_path = default_template_name, object = nil, local_assigns = {}) and render_partial_collection(partial_name, collection, partial_spacer_template = nil, local_assigns = {}).
File rendering works just like action rendering except that it takes a path relative to the template root or an absolute path if use_full_path is passed as true. The current layout is not applied automatically.
# Renders the template located in [TEMPLATE_ROOT]/weblog/show.r(html|xml) (in Rails, app/views/weblog/show.rhtml) render :file => "weblog/show" # Renders the template located in /path/to/some/template.r(html|xml) render :file => "/path/to/some/template", :use_full_path => false # Renders the same template within the current layout, but with a 404 status code render :file => "/path/to/some/template", :use_full_path => false, :layout => true, :status => 404
Deprecation notice: This used to have the signature render_file(path, status = 200)
Rendering of text is usually used for tests or for rendering prepared content, such as a cache. By default, text rendering is not done within the active layout.
# Renders the clear text "hello world" with status code 200 render :text => "hello world!" # Renders the clear text "Explosion!" with status code 500 render :text => "Explosion!", :status => 500 # Renders the clear text "Hi there!" within the current active layout (if one exists) render :text => "Explosion!", :layout => true # Renders the clear text "Hi there!" within the the layout # placed in "app/views/layouts/special.r(html|xml)" render :text => "Explosion!", :layout => "special"
Deprecation notice: This used to have the signature render_text("text", status = 200)
Rendering of an inline template works as a cross between text and action rendering where the source for the template is supplied inline, like text, but its interpreted with ERb or Builder, like action. By default, ERb is used for rendering and the current layout is not used.
# Renders "hello, hello, hello, again" render :inline => "<%= 'hello, ' * 3 + 'again' %>" # Renders "<p>Good seeing you!</p>" using Builder render :inline => "xml.p { 'Good seeing you!' }", :type => :rxml # Renders "hello david" render :inline => "<%= 'hello ' + name %>", :locals => { :name => "david" }
Deprecation notice: This used to have the signature render_template(template, status = 200, type = :rhtml)
Rendering nothing is often convenient in combination with Ajax calls that perform their effect client-side or when you just want to communicate a status code.
# Renders an empty response with status code 200 render :nothing => true # Renders an empty response with status code 401 (access denied) render :nothing => true, :status => 401
# File vendor/rails/actionpack/lib/action_controller/base.rb, line 569 569: def render(options = {}, deprecated_status = nil) #:doc: 570: # puts "Rendering: #{options.inspect}" 571: raise DoubleRenderError if performed? 572: 573: # Backwards compatibility 574: return render({ :template => options || default_template_name, :status => deprecated_status }) if !options.is_a?(Hash) 575: 576: add_variables_to_assigns 577: options[:status] = (options[:status] || DEFAULT_RENDER_STATUS_CODE).to_s 578: 579: if options[:text] 580: @response.headers["Status"] = options[:status] 581: @response.body = options[:text] 582: @performed_render = true 583: return options[:text] 584: 585: elsif options[:file] 586: assert_existance_of_template_file(options[:file]) if options[:use_full_path] 587: logger.info("Rendering #{options[:file]} (#{options[:status]})") unless logger.nil? 588: render(options.merge({ :text => @template.render_file(options[:file], options[:use_full_path])})) 589: 590: elsif options[:template] 591: render(options.merge({ :file => options[:template], :use_full_path => true })) 592: 593: elsif options[:inline] 594: render(options.merge({ 595: :text => 596: @template.render_template( 597: options[:type] || :rhtml, 598: options[:inline], 599: options[:locals] || {} 600: ) 601: })) 602: 603: elsif options[:action] 604: render(options.merge({ :template => default_template_name(options[:action]) })) 605: 606: elsif options[:partial] && options[:collection] 607: render(options.merge({ 608: :text => ( 609: @template.render_partial_collection( 610: options[:partial] == true ? default_template_name : options[:partial], 611: options[:collection], options[:spacer_template], 612: options[:locals] || {} 613: ) || '' 614: ) 615: })) 616: 617: elsif options[:partial] 618: render(options.merge({ :text => @template.render_partial( 619: options[:partial] == true ? default_template_name : options[:partial], 620: options[:object], options[:locals] || {} 621: ) })) 622: 623: elsif options[:nothing] 624: render(options.merge({ :text => "" })) 625: 626: else 627: render(options.merge({ :action => action_name })) 628: end 629: end
Renders according to the same rules as render, but returns the result in a string instead of sending it as the response body to the browser.
# File vendor/rails/actionpack/lib/action_controller/base.rb, line 633 633: def render_to_string(options = {}) #:doc: 634: result = render(options) 635: erase_render_results 636: return result 637: end
Resets the session by clearing out all the objects stored within and initializing a new session object.
# File vendor/rails/actionpack/lib/action_controller/base.rb, line 716 716: def reset_session #:doc: 717: @request.reset_session 718: @session = @request.session 719: @response.session = @session 720: end