class ActionController::Base

end
render action: “overthere” # won’t be called if monkeys is nil
redirect_to(action: “elsewhere”) and return if monkeys.nil?
def do_something
If you need to redirect on the condition of something, then be sure to add “and return” to halt execution.
end
render action: “overthere” # raises DoubleRenderError
redirect_to action: “elsewhere”
def do_something
An action may contain only a single render or a single redirect. Attempting to try to do either again will result in a DoubleRenderError:
== Calling multiple redirects or renders
Learn more about redirect_to and what options you have in ActionController::Redirecting.
and not some internal re-routing which calls both “create” and then “show” within one request.
Note that this is an external HTTP-level redirection which will cause the browser to make a second request (a GET to the show action),
In this case, after saving our new entry to the database, the user is redirected to the show method, which is then executed.
end
end
# things didn’t go so well, do something else
else
redirect_to action: ‘show’, id: @entry.id
# The entry was saved correctly, redirect to show
if @entry.save
@entry = Entry.new(params)
def create
going to reuse (and redirect to) a show action that we’ll assume has already been created. The code might look like this:
database, we might like to show the user the new entry. Because we’re following good DRY principles (Don’t Repeat Yourself), we’re
Redirects are used to move from one action to another. For example, after a create action, which stores a blog entry to the
== Redirects
Read more about writing ERB and Builder templates in ActionView::Base.
end
end
when 2..10 then render action: “show_many”
when 1 then render action: “show”
when 0 then render action: “no_results”
case @results.count
@results = Search.find(params)
def search
will use the manual rendering methods:
You don’t have to rely on the automated rendering. For example, actions that could result in the rendering of different templates
Title: <%= @post.title %>
Which are then automatically available to the view:
end
@post = Post.find(params)
def show
The controller passes objects to the view by assigning instance variables:
of a template. Included in the Action Pack is the Action View, which enables rendering of ERB templates. It’s automatically configured.
Action Controller sends content to the user by using one of five rendering methods. The most versatile and common is the rendering
== Renders
object is generated automatically through the use of renders and redirects and requires no user intervention.
Each action results in a response, which holds the headers and document to be sent to the user’s browser. The actual response
== Responses
information in cookie-based sessions.
cookie even after it has expired, so you should avoid storing sensitive
read or edit the session data. However, the user can keep a copy of the
ActionDispatch::Session::CookieStore). Thus the user will not be able to
By default, sessions are stored in an encrypted browser cookie (see
or you can remove the entire session with reset_session.<br><br>session = nil
# removes :person from session
For removing objects from the session, you can either assign a single key to nil:
“Hello #{session}”
You can retrieve it again through the same hash:<br><br>session = Person.authenticate(user_name, password)
You can place objects in the session by using the session method, which accesses a hash:
they could be changed unknowingly. It’s usually too much work to keep it all synchronized – something databases already excel at.
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
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
Sessions allow you to store objects in between requests. This is useful for objects that are not yet ready to be persisted,
== Sessions
{ "post" => { "address" => { "street" => "hyacintvej" } } }. There’s no limit to the depth of the nesting.
If the address input had been named post[address][street], the params would have included
A request coming from a form holding these inputs will include { "post" => { "name" => "david", "address" => "hyacintvej" } }.
<input type=“text” name=“post” value=“hyacintvej”>
<input type=“text” name=“post” value=“david”>
It’s also possible to construct multi-dimensional parameter hashes by specifying keys using brackets, such as:
/posts?category=All&limit=5 will include { "category" => "All", "limit" => "5" } in params.
available through the params method which returns a hash. For example, an action that was performed through
All request parameters, whether they come from a query string in the URL or form data submitted through a POST request are
== Parameters
end
render plain: “This server hosted at #{location}”
location = request.env[“REMOTE_ADDR”]
def server_ip
The full request object is available via the request accessor and is primarily used to query for HTTP headers:
all the HTTP headers are made available to the action through accessor methods. Then the action is performed.
and action are called. The remaining request parameters, the session (if one is available), and the full request with
For every request, the router determines the value of the controller and action keys. These determine which controller
== Requests
Most actions are variations on these themes.
These two methods represent the two basic action archetypes used in Action Controllers: Get-and-show and do-and-redirect.
302 Moved HTTP response that takes the user to the index action.
new post), it initiates a redirect instead. This redirect works by returning an external
Unlike index, the create action will not render a template. After performing its main purpose (creating a
template app/views/posts/index.html.erb by default after populating the @posts instance variable.
after executing code in the action. For example, the index action of the PostsController would render the
Actions, by default, render a template in the app/views directory corresponding to the name of the controller and action
end
end
redirect_to posts_path
@post = Post.create params[:post]
def create
end
@posts = Post.all
def index
class PostsController < ApplicationController
A sample controller could look like this:
request forgery protection and filtering of sensitive request parameters.
controllers inherit from ApplicationController. This gives you one class to configure things such as
By default, only the ApplicationController in a Rails application inherits from ActionController::Base. All other
on the controller, which will automatically be made accessible to the web-server through Rails Routes.
on request and then either it renders a template or redirects to another action. An action is defined as a public method
Action Controllers are the core of a web request in Rails. They are made up of one or more actions that are executed