ActionPack is a Rails framework that handles web requests and responses. It consists of Action Controller, which performs request logic and fetches/saves data from models, and Action View, which renders templates using views. Action Controller uses conventions to handle requests and provides parameters, filters, flashes, and variants to manage requests and responses. Action View renders templates using helpers and can be used independently of Active Record.

1. ActionPack – From request to response
1 / 17

2. What is ActionPack?
ActionPack is a:
1. RoR module or component;
2. gem actionpack 4.1.6
3. framework for handling and responding to web requests (the V&C layers
in MVC paradigm)
2 / 17

3. It consists of:
2 major components:
1. Action Controller – performing the logic
2. Action View – rendering a template # this will be extracted into a new
gem from version 4.1.
Now, it only has this big Action Controller, which does all the staf to handle
requests and responses for every rails controller.
3 / 17

4. What does ActionController?
Action Controller takes the request passed by router and does the
groundwork for producing the response.
Also uses a set of smart conventions to handle the request (invisible for
developer) – RESTful, naming conv., folders, extensions etc.
Fetch or save data from a model and use a view (Action View) to create
the output.
# app/controollers/application_controller.rb
class ApplicationController < ActionController::Base
# Prevent CSRF attacks by raising an exception.
# For APIs, you may want to use :null_session instead.
protect_from_forgery with: :exception
end
4 / 17

5. What does ActionView?
renders a template, using embedded ruby mingled with HTML or HAML.
provides a set of helpers classes for handling common behavior for forms,
dates and strings.
Some features of Action View are tied to Active Record, but that
doesn't mean Action View depends on Active Record. Action View is
an independent package that can be used with any sort of Ruby
libraries. -- Rails Guides
Sample view using en ERB template:
<h1>Names of all ruby developers</h1>
<% @developers.each do |person| %>
Name: <%= person.name %><br>
<% end %>
5 / 17

6. I. Action Controller
1. Conventions
2. Parameters
3. Filters
4. Flashes
5. Variants
6 / 17

7. I.1 Conventions
Controller naming conventions:
camelcase, always ending in ...Controller,
plural over/versus singular form of the last but one word.
MyApp::Application.routes.draw do
resources :developers # mapped to DevelopersController
resource :profile # ! ProfilesController
end
MyApp::Application.routes.draw do
resource :profile, controller: 'profile' # override the default plural convention
end
Methods and actions:
snakecase, routing action name = controller method name
public methods are most of the time actions
move to private visibility all auxiliary methods or filters
7 / 17

8. I.2 Parameters
GET, POST, PATCH, PUT parameters go into a new instance of
ActionController::Parameters, and this instance is provided by params
helper method
Hash and Array Parameters
routing parameters
get '/developers/:status' => 'developers#index', foo: 'bar'
# ...
URL /developers/active
# ...
puts params[:status] # => active
default_url_options
class ApplicationController < ActionController::Base
def default_url_options
{ locale: I18n.locale }
end
end
8 / 17

9. I.2 Parameters(2)
Strong parameters
def create
Person.create(person_params)
end
private
def person_params
params.require(:person).permit(:name, :age)
end
you can also use permit on nested parameters
params.require(:person).permit(:name, { emails: [] },
friends: [ :name,
{ family: [ :name ], hobbies: [] }])
9 / 17

10. I.3 Filters
are methods that are run before, after or "around" a controller action.
are inherited, so if you set a filter on ApplicationController, it will be run
on every controller in your application.
Example:
class ApplicationController < ActionController::Base
before_action :require_login
private
def require_login
unless logged_in?
flash[:error] = "You must be logged in to access this section"
redirect_to new_login_url # halts request cycle
end
end
end
10 / 17

11. I.3 Filters(2)
More examples:
skip_[before|after|around]_action, only: or except:
class LoginsController < ApplicationController
skip_before_action :require_login, only: [:new, :create]
end
? follow Open Closed Principle
around_action - a before&after filter !?
class ChangesController < ApplicationController
around_action :wrap_in_transaction, only: :show
private
def wrap_in_transaction
ActiveRecord::Base.transaction do
begin
yield
ensure
raise ActiveRecord::Rollback
end
end 11 / 17

12. I.4 Flashes
The flash is a special part of the session which is cleared with each request. It
is useful for passing messages (error messsages) form last request. There are
two predefined flash keys :notice and :alert, but you can use any other
custom keys.
Usage examples:
class LoginsController < ApplicationController
def destroy
session[:current_user_id] = nil
flash[:notice] = "You have successfully logged out."
redirect_to root_url
end
end
or assign a flash message as part of the redirection:
redirect_to root_url, notice: "You have successfully logged out."
redirect_to root_url, alert: "You're stuck here!"
redirect_to root_url, flash: { referral_code: 1234 }
12 / 17

13. I.4 Flashes(2) - useful methods
Flashes are available on session only for the next request. But you can alter
this default behavior in two ways:
1. using flash.keep method
class MainController < ApplicationController
# Let's say this action corresponds to root_url, but you want
# all requests here to be redirected to UsersController#index.
# If an action sets the flash and redirects here, the values
# would normally be lost when another redirect happens, but you
# can use 'keep' to make it persist for another request.
def index
# Will persist all flash values.
flash.keep
# You can also use a key to keep only some kind of value.
# flash.keep(:notice)
redirect_to users_url
end
end
13 / 17

14. I.4 Flashes(3) - useful methods
1. using flash.now mehtod
class ClientsController < ApplicationController
def create
@client = Client.new(params[:client])
if @client.save
# ...
else
flash.now[:error] = "Could not save client"
render action: "new"
end
end
end
rails 4.1 FlashHash now behaves like a HashWithIndifferentAccess.
flash[:notice] # => 'Successful login.'
flash['notice'] # => 'Successful login.'
14 / 17

15. I.5 ActionPack Variants (rails 4.1)
We often want to render different html/json/xml templates for phones, tablets,
and desktop browsers. Variants make it easy.
The request variant is a specialization of the request format, like :tablet,
:phone, or :desktop.
It can be set using a before_action :
def set_variants
request.variant = :tablet if request.user_agent =~ /iPad/
....
end
Respond to variants in the action just like you respond to formats:
respond_to do |format|
format.html do |html|
html # renders app/views/projects/show.html.erb
html.tablet # renders app/views/projects/show.html+tablet.erb
html.phone { extra_setup } # renders app/views/projects/show.html+phone.erb
end
end
15 / 17

16. I.5 ActionPack Variants(2)
Variants also support the common any/all block that formats have.
It works for both inline:
respond_to do |format|
format.html.any { render text: "any" }
format.html.phone { render text: "phone" }
end
and block syntax:
respond_to do |format|
format.html do |variant|
variant.any(:tablet, :phablet) { render text: "ablet html template" }
variant.phone { render text: "phone" }
end
end
16 / 17

17. Resources
Rails Guides
Rails API doc
Action Pack 4.1 changelog
17 / 17