This is a block of Ruby code that takes advantage of a Rails helper method. If you aren't familiar with blocks yet, you will see them a lot in Ruby.
respond_to
is a Rails helper method that is attached to the Controller class (or rather, its super class). It is referencing the response that will be sent to the View (which is going to the browser).
The block in your example is formatting data - by passing in a 'format' paramater in the block - to be sent from the controller to the view whenever a browser makes a request for html or json data.
If you are on your local machine and you have your Post scaffold set up, you can go to http://localhost:3000/posts
and you will see all of your posts in html format. But, if you type in this: http://localhost:3000/posts.json
, then you will see all of your posts in a json object sent from the server.
This is very handy for making javascript heavy applications that need to pass json back and forth from the server. If you wanted, you could easily create a json api on your rails back-end, and only pass one view - like the index view of your Post controller. Then you could use a javascript library like Jquery or Backbone (or both) to manipulate data and create your own interface. These are called asynchronous UIs and they are becomming really popular (Gmail is one). They are very fast and give the end-user a more desktop-like experience on the web. Of course, this is just one advantage of formatting your data.
The Rails 3 way of writing this would be this:
class PostsController < ApplicationController
# GET /posts
# GET /posts.xml
respond_to :html, :xml, :json
def index
@posts = Post.all
respond_with(@posts)
end
#
# All your other REST methods
#
end
By putting respond_to :html, :xml, :json
at the top of the class, you can declare all the formats that you want your controller to send to your views.
Then, in the controller method, all you have to do is respond_with(@whatever_object_you_have)
It just simplifies your code a little more than what Rails auto-generates.
If you want to know about the inner-workings of this...
From what I understand, Rails introspects the objects to determine what the actual format is going to be. The 'format' variables value is based on this introspection. Rails can do a whole lot with a little bit of info. You'd be surprised at how far a simple @post or :post will go.
For example, if I had a _user.html.erb partial file that looked like this:
_user.html.erb
<li>
<%= link_to user.name, user %>
</li>
Then, this alone in my index view would let Rails know that it needed to find the 'users' partial and iterate through all of the 'users' objects:
index.html.erb
<ul class="users">
<%= render @users %>
</ul>
would let Rails know that it needed to find the 'user' partial and iterate through all of the 'users' objects:
You may find this blog post useful: http://archives.ryandaigle.com/articles/2009/8/6/what-s-new-in-edge-rails-cleaner-restful-controllers-w-respond_with
You can also peruse the source: https://github.com/rails/rails