class ActionController::Responder

Using respond_with with a block follows the same syntax as respond_to.
end
end
end
format.html { render “some_special_template”, status: :unprocessable_entity }
= ‘Task was successfully created.’
if @task.save
respond_with(@project, @task, status: 201) do |format|
@task = @project.tasks.build(params)
@project = Project.find(params)
def create
respond_with:
To customize the failure scenario, you can pass a block to
respond_with(@project, location: root_path)
resource errors. You can also override the location to redirect to:
it will simply ignore the given options and return status 422 and the
This will return status 201 if the task was saved successfully. If not,
end
respond_with(@project, @task, status: 201)<br>flash = ‘Task was successfully created.’ if @task.save
@task = @project.tasks.build(params)
@project = Project.find(params)
def create
scenarios. For instance, you can do the following in the create method above:
to the underlying render call. Those options are only applied for success
respond_with also allows you to pass options that are forwarded
=== Custom options
respond_with [@project, :manager, @task]
so the following is not equivalent:
Note that if you give an array, it will be treated as a collection,
respond_with(@project, :manager, @task)
should be invoked as:
polymorphic urls. If a project has one manager which has many tasks, it
Namespaced and singleton resources require a symbol to be given, as in
project_task_url instead of task_url.
Giving several resources ensures that the responder will redirect to
end
respond_with(@project, @task)<br>flash = ‘Task was successfully created.’ if @task.save
@task = @project.tasks.build(params)
@project = Project.find(params)
def create
TasksController would be like:
Consider the project has many tasks example. The create action for
You can supply nested resources as you do in form_for and polymorphic_url.
=== Nested resources
The same happens for PATCH/PUT and DELETE requests.
end
end
end
format.xml { render xml: @user.errors, status: :unprocessable_entity }
format.html { render action: “new”, status: :unprocessable_entity }
else
format.xml { render xml: @user, status: :created, location: @user }
format.html { redirect_to(@user) }
= ‘User was successfully created.’
if @user.save
respond_to do |format|
@user = User.new(params)
def create
Which is exactly the same as:<br><br>end<br>respond_with(@user)<br>flash = ‘User was successfully created.’ if @user.save
@user = User.new(params)
def create
be written as:
Using Rails default responder, a POST request for creating an object could
content type, verb and the resource status, it will behave differently.
The default Rails responder holds semantics for each HTTP verb. Depending on the
=== Built-in HTTP verb semantics
3) if the responder does not respond_to :to_xml, call #to_format on it.
2) if the template is not available, it will invoke #to_xml on the given resource;
1) the responder searches for a template at people/index.xml;
When a request comes in, for example for an XML response, three steps happen:
end
end
respond_with(@people)
@people = Person.all
def index
respond_to :html, :xml, :json
class PeopleController < ApplicationController
respond_with is called. The simplest case to study is a GET request:
usually depending on the HTTP verb. The responder is triggered when
Responsible for exposing a resource to different mime requests,
:nodoc:

def self.call(*args)


not defined, call to_format.
Initializes a new responder and invokes the proper format. If the format is 
def self.call(*args)
  new(*args).respond
end

def api_behavior

This is the common behavior for formats associated with APIs, such as :xml and :json. 
def api_behavior
  raise MissingRenderer.new(format) unless has_renderer?
  if get?
    display resource
  elsif post?
    display resource, status: :created, location: api_location
  else
    head :no_content
  end
end

def default_action


the verb was POST.
By default, render the :edit action for HTML requests with errors, unless 
def default_action
  @action ||= DEFAULT_ACTIONS_FOR_VERBS[request.request_method_symbol]
end

def default_render


controller.
If a response block was given, use it, otherwise call render on 
def default_render
  if @default_response
    @default_response.call(options)
  elsif !get? && has_errors?
    controller.render({ status: error_status }.merge!(options))
  else
    controller.render(options)
  end
end

def display(resource, given_options = {})


render xml: @user, status: :created

Results in:

display(@user, status: :ok)
respond_with(@user, status: :created)

Options sent by the user are also used:

render xml: @user, status: :ok

For XML requests it's equivalent to:

display @user, status: :ok

Display is just a shortcut to render a resource with the current format. 
def display(resource, given_options = {})
  controller.render given_options.merge!(options).merge!(format => resource)
end

def display_errors 

def display_errors
  # TODO: use `error_status` once we switch the default to be `unprocessable_entity`,
  # otherwise we'd be changing this behavior here now.
  controller.render format => resource_errors, :status => :unprocessable_entity
end

def error_rendering_options 

def error_rendering_options
  if options[:render]
    options[:render]
  else
    { action: default_action, status: error_status }
  end
end

def has_errors?


Check whether the resource has errors. 
def has_errors?
  resource.respond_to?(:errors) && !resource.errors.empty?
end

def has_renderer?

Check whether the necessary Renderer is available 
def has_renderer?
  Renderers::RENDERERS.include?(format)
end

def has_view_rendering? 

def has_view_rendering?
  controller.class.include? ActionView::Rendering
end

def initialize(controller, resources, options = {}) 

def initialize(controller, resources, options = {})
  @controller = controller
  @request = @controller.request
  @format = @controller.formats.first
  @resource = resources.last
  @resources = resources
  @options = options
  @action = options.delete(:action)
  @default_response = options.delete(:default_response)
  if options[:location].respond_to?(:call)
    location = options.delete(:location)
    options[:location] = location.call unless has_errors?
  end
end

def json_resource_errors 

def json_resource_errors
  { errors: resource.errors }
end

def navigation_behavior(error)

This is the common behavior for formats associated with browsing, like :html, :iphone and so forth. 
def navigation_behavior(error)
  if get?
    raise error
  elsif has_errors? && default_action
    render error_rendering_options
  else
    redirect_to navigation_location, status: redirect_status
  end
end

def resource_errors 

def resource_errors
  respond_to?("#{format}_resource_errors", true) ? send("#{format}_resource_errors") : resource.errors
end

def resource_location


returning the resources array.
Returns the resource location by retrieving it from the options or 
def resource_location
  options[:location] || resources
end

def respond


Main entry point for responder responsible to dispatch to the proper format. 
def respond
  method = "to_#{format}"
  respond_to?(method) ? send(method) : to_format
end

def response_overridden? 

def response_overridden?
  @default_response.present?
end

def to_format


responds to :to_format and display it.
template, if the template is not available, we verify if the resource
All other formats follow the procedure below. First we try to render a 
def to_format
  if !get? && has_errors? && !response_overridden?
    display_errors
  elsif has_view_rendering? || response_overridden?
    default_render
  else
    api_behavior
  end
rescue ActionView::MissingTemplate
  api_behavior
end

def to_html


template.
HTML format does not render the resource, it always attempt to render a 
def to_html
  default_render
rescue ActionView::MissingTemplate => e
  navigation_behavior(e)
end

def to_js

to_js simply tries to render a template. If no template is found, raises the error. 
def to_js
  default_render
end