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. This change will be visible for all future requests.
ArticleController.append_view_path("views/default")
ArticleController.append_view_path(["views/default", "views/custom"])
Converts the class name from something like "OneModule::TwoModule::NeatController" to "NeatController".
Converts the class name from something like "OneModule::TwoModule::NeatController" to "neat".
Converts the class name from something like "OneModule::TwoModule::NeatController" to "one_module/two_module/neat".
Don’t render layouts for templates with the given extensions.
Replace sensitive parameter data from the request log. Filters parameters that have any of the arguments as a substring. Looks in all subhashes of the param hash for keys to filter. If a block is given, each key and value of the parameter hash and all subhashes is passed to it, the value or key can be replaced using String#replace or similar method.
Examples:
filter_parameter_logging
=> Does nothing, just slows the logging process down
filter_parameter_logging :password
=> replaces the value to all keys matching /password/i with "[FILTERED]"
filter_parameter_logging :foo, "bar"
=> replaces the value to all keys matching /foo|bar/i with "[FILTERED]"
filter_parameter_logging { |k,v| v.reverse! if k =~ /secret/i }
=> reverses the value to all keys matching /secret/i
filter_parameter_logging(:foo, "bar") { |k,v| v.reverse! if k =~ /secret/i }
=> reverses the value to all keys matching /secret/i, and
replaces the value to all keys matching /foo|bar/i with "[FILTERED]"
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.
Hide each of the given methods from being callable as actions.
Adds a view_path to the front of the view_paths array. If the current class has no view paths, copy them from the superclass. This change will be visible for all future requests.
ArticleController.prepend_view_path("views/default")
ArticleController.prepend_view_path(["views/default", "views/custom"])
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:
Process a test request called with a TestRequest object.
View load paths determine the bases from which template references can be made. So a call to render("test/template") will be looked up in the view load paths array and the closest match will be returned.
Adds a view_path to the end of the view_paths array. This change affects the current request only.
self.append_view_path("views/default")
self.append_view_path(["views/default", "views/custom"])
Converts the class name from something like "OneModule::TwoModule::NeatController" to "NeatController".
Converts the class name from something like "OneModule::TwoModule::NeatController" to "neat".
Converts the class name from something like "OneModule::TwoModule::NeatController" to "one_module/two_module/neat".
Adds a view_path to the front of the view_paths array. This change affects the current request only.
self.prepend_view_path("views/default")
self.prepend_view_path(["views/default", "views/custom"])
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 => 'index', :port=>'8033' # => 'proto://host.com:8033/posts' url_for :controller => 'posts', :action => 'show', :id => 10 # => 'proto://host.com/posts/show/10' url_for :controller => 'posts', :user => 'd', :password => '123' # => 'proto://d:123@host.com/posts'
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 of 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 its own, this rule can account for much of the typical Rails URL behavior. Although a convenience, defaults can occasionally 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.
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 endActions, 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}" endParameters
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:
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:
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.
Sessions are stored in a browser cookie that’s cryptographically signed, but unencrypted, by default. This prevents the user from tampering with the session but also allows him to see its contents.
Do not put secret information in session!
Other options for session storage are:
ActiveRecordStore: sessions are stored in your database, which works better than PStore with multiple app servers and, unlike CookieStore, hides your session contents from the user. To use ActiveRecordStore, set
in your environment.rb and run rake db:sessions:create.
MemCacheStore: sessions are stored as entries in your memcached cache. Set the session store type in environment.rb:
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]) endWhich are then automatically available to the view:
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 endRead more about writing ERb and Builder templates in ActionView::Base.
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 endIn 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 may contain only a single render or a single 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 endIf 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