Class: ActionController::Base

Inherits:
Object
  • Object
show all
Includes:
Reloadable::Subclasses
Defined in:
lib/action_controller/base.rb,
lib/action_controller/cgi_process.rb,
lib/action_controller/test_process.rb,
lib/action_controller/deprecated_redirects.rb

Overview

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

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

Parameters

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[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 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.

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, so it’s normally nothing you’ll need to be concerned about.

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

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 being 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'

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

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) }

Constant Summary collapse

DEFAULT_RENDER_STATUS_CODE = 
"200 OK"
@@view_controller_internals =

Determines whether the view has access to controller internals @request, @response, @session, and @template. By default, it does.

true
@@protected_variables_cache =

Protected instance variable cache

nil
@@asset_host =

Prepends all the URL-generating helpers from AssetHelper. This makes it possible to easily move javascripts, stylesheets, and images to a dedicated asset server away from the main web server. Example: 

ActionController::Base.asset_host = "http://assets.example.com"

""
@@consider_all_requests_local =

All requests are considered local by default, so everyone will be exposed to detailed debugging screens on errors. When the application is ready to go public, this should be set to false, and the protected method local_request? should instead be implemented in the controller to determine when debugging screens should be shown.

true
@@debug_routes =

Enable or disable the collection of failure information for RoutingErrors. This information can be extremely useful when tweaking custom routes, but is pointless once routes have been tested and verified.

true
@@allow_concurrency =

Controls whether the application is thread-safe, so multi-threaded servers like WEBrick know whether to apply a mutex around the performance of each action. Action Pack and Active Record are by default thread-safe, but many applications may not be. Turned off by default.

false
@@param_parsers =

Modern REST web services often need to submit complex data to the web application. The param_parsers hash lets you register handlers wich will process the http body and add parameters to the By default application/xml is enabled. A XmlSimple class with the same param name as the root will be instanciated in the @params. This allows XML requests to mask themselves as regular form submissions, so you can have one action serve both regular forms and web service requests.

Example of doing your own parser for a custom content type:

ActionController::Base.param_parsers[Mime::Type.lookup('application/atom+xml')] = Proc.new do |data| 
   node = REXML::Document.new(post) 
  { node.root.name => node.root }
end

Note: Up until release 1.1 of Rails, Action Controller would default to using XmlSimple configured to discard the root node for such requests. The new default is to keep the root, such that “<r><name>David</name></r>” results in params[:name] for “David” instead of params. To get the old behavior, you can re-register XmlSimple as application/xml handler ike this:

ActionController::Base.param_parsers[Mime::XML] = 
  Proc.new { |data| XmlSimple.xml_in(data, 'ForceArray' => false) }

A YAML parser is also available and can be turned on with:

ActionController::Base.param_parsers[Mime::YAML] = :yaml

{ Mime::XML => :xml_simple }

Instance Attribute Summary collapse

Class Method Summary collapse

Instance Method Summary collapse

Instance Attribute Details

#action_name ⇒ Object

Returns the name of the action this controller is processing.



334
335
336
 
# File 'lib/action_controller/base.rb', line 334

def action_name
  @action_name
end

#assigns ⇒ Object

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.



331
332
333
 
# File 'lib/action_controller/base.rb', line 331

def assigns
  @assigns
end

#headers ⇒ Object

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.



327
328
329
 
# File 'lib/action_controller/base.rb', line 327

def headers
  @headers
end

#params ⇒ Object

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.



313
314
315
 
# File 'lib/action_controller/base.rb', line 313

def params
  @params
end

#request ⇒ Object

Holds the request object that’s primarily used to get environment variables through access like request.env["REQUEST_URI"].



309
310
311
 
# File 'lib/action_controller/base.rb', line 309

def request
  @request
end

#response ⇒ Object

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.



319
320
321
 
# File 'lib/action_controller/base.rb', line 319

def response
  @response
end

#session ⇒ Object

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 or symbol.



323
324
325
 
# File 'lib/action_controller/base.rb', line 323

def session
  @session
end

Class Method Details

.controller_class_name ⇒ Object

Converts the class name from something like “OneModule::TwoModule::NeatController” to “NeatController”.



343
344
345
 
# File 'lib/action_controller/base.rb', line 343

def controller_class_name
  @controller_class_name ||= name.demodulize
end

.controller_name ⇒ Object

Converts the class name from something like “OneModule::TwoModule::NeatController” to “neat”.



348
349
350
 
# File 'lib/action_controller/base.rb', line 348

def controller_name
  @controller_name ||= controller_class_name.sub(/Controller$/, '').underscore
end

.controller_path ⇒ Object

Converts the class name from something like “OneModule::TwoModule::NeatController” to “one_module/two_module/neat”.



353
354
355
 
# File 'lib/action_controller/base.rb', line 353

def controller_path
  @controller_path ||= name.gsub(/Controller$/, '').underscore
end

.hidden_actions ⇒ Object

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.



360
361
362
363
 
# File 'lib/action_controller/base.rb', line 360

def hidden_actions
  write_inheritable_attribute(:hidden_actions, ActionController::Base.public_instance_methods) unless read_inheritable_attribute(:hidden_actions)
  read_inheritable_attribute(:hidden_actions)
end

.hide_action(*names) ⇒ Object

Hide each of the given methods from being callable as actions.



366
367
368
 
# File 'lib/action_controller/base.rb', line 366

def hide_action(*names)
  write_inheritable_attribute(:hidden_actions, hidden_actions | names.collect { |n| n.to_s })
end

.process(request, response) ⇒ Object

Factory for the standard create, process loop where the controller is discarded after processing.



338
339
340
 
# File 'lib/action_controller/base.rb', line 338

def process(request, response) #:nodoc:
  new.process(request, response)
end

.process_cgi(cgi = CGI.new, session_options = {}) ⇒ Object

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:

  • :database_manager - standard options are CGI::Session::FileStore, CGI::Session::MemoryStore, and CGI::Session::PStore (default). Additionally, there is CGI::Session::DRbStore and CGI::Session::ActiveRecordStore. Read more about these in lib/action_controller/session.

  • :session_key - the parameter name used for the session id. Defaults to ‘_session_id’.

  • :session_id - the session id to use. If not provided, then it is retrieved from the session_key parameter of the request, or automatically generated for a new session.

  • :new_session - if true, force creation of a new session. If not set, a new session is only created if none currently exists. If false, a new session is never created, and if none currently exists and the session_id option is not set, an ArgumentError is raised.

  • :session_expires - the time the current session expires, as a Time object. If not set, the session will continue indefinitely.

  • :session_domain - the hostname domain for which this session is valid. If not set, defaults to the hostname of the server.

  • :session_secure - if true, this session will only work over HTTPS.

  • :session_path - the path for which this session applies. Defaults to the directory of the CGI script.



25
26
27
 
# File 'lib/action_controller/cgi_process.rb', line 25

def self.process_cgi(cgi = CGI.new, session_options = {}) 
  new.process_cgi(cgi, session_options)
end

.process_test(request) ⇒ Object

Process a test request called with a TestRequest object.



7
8
9
 
# File 'lib/action_controller/test_process.rb', line 7

def self.process_test(request)
  new.process_test(request)
end

Instance Method Details

#controller_class_name ⇒ Object

Converts the class name from something like “OneModule::TwoModule::NeatController” to “NeatController”.



466
467
468
 
# File 'lib/action_controller/base.rb', line 466

def controller_class_name
  self.class.controller_class_name
end

#controller_name ⇒ Object

Converts the class name from something like “OneModule::TwoModule::NeatController” to “neat”.



471
472
473
 
# File 'lib/action_controller/base.rb', line 471

def controller_name
  self.class.controller_name
end

#process_cgi(cgi, session_options = {}) ⇒ Object

:nodoc:



29
30
31
 
# File 'lib/action_controller/cgi_process.rb', line 29

def process_cgi(cgi, session_options = {}) #:nodoc:
  process(CgiRequest.new(cgi, session_options), CgiResponse.new(cgi)).out
end

#process_test(request) ⇒ Object

:nodoc:



11
12
13
 
# File 'lib/action_controller/test_process.rb', line 11

def process_test(request) #:nodoc:
  process(request, TestResponse.new)
end

#process_with_test(*args) ⇒ Object Also known as: process 



15
16
17
18
19
 
# File 'lib/action_controller/test_process.rb', line 15

def process_with_test(*args)
  returning process_without_test(*args) do
    add_variables_to_assigns
  end
end

#session_enabled? ⇒ Boolean

Returns:

  • (Boolean) 


475
476
477
 
# File 'lib/action_controller/base.rb', line 475

def session_enabled?
  request.session_options[:disabled] != false
end

#url_for(options = {}, *parameters_for_method_reference) ⇒ Object

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:

  • :anchor – specifies the anchor name to be appended to the path. For example, url_for :controller => 'posts', :action => 'show', :id => 10, :anchor => 'comments' will produce “/posts/show/10#comments”.

  • :only_path – if true, returns the absolute URL (omitting the protocol, host name, and port)

  • :trailing_slash – if true, adds a trailing slash, as in “/archive/2005/”. Note that this is currently not recommended since it breaks caching.

  • :host – overrides the default (current) host if provided

  • :protocol – overrides the default (current) protocol if provided

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:

  • If the controller name begins with a slash, no defaults are used: url_for :controller => '/home'

  • If the controller changes, the action will default to index unless provided

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 of URLs which are generated from this page.

  • url_for :action => 'bio' – During the generation of this URL, default values will be used for the first and

last components, and the action shall change. The generated URL will be, “people/hh/david/bio”.

  • url_for :first => 'davids-little-brother' This generates the URL ‘people/hh/davids-little-brother’ – note that this URL leaves out the assumed action of ‘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

If you explicitly want to create a URL that’s almost the same as the current URL, you can do so using the :overwrite_params options. Say for your posts you have different views for showing and printing them. Then, in the show view, you get the URL for the print view like this

url_for :overwrite_params => { :action => 'print' }

This takes the current URL as is and only exchanges the action. In contrast, url_for :action => 'print' would have slashed-off the path components after the changed action.



457
458
459
460
461
462
463
 
# File 'lib/action_controller/base.rb', line 457

def url_for(options = {}, *parameters_for_method_reference) #:doc:
  case options
    when String then options
    when Symbol then send(options, *parameters_for_method_reference)
    when Hash   then @url.rewrite(rewrite_options(options))
  end
end