Section 5.1. The Big Picture | Ruby on Rails[c] Up and Running

5.1. The Big Picture

Let's step back for a moment to examine the processing steps that occur from the time the server receives a URL request to when Rails finally returns the resulting HTML response (affectionately know as the big picture ):

The web server receives a request from the browser. A request consists mostly of a URL and some optional parameters (which may or may not be part of the URL).
The web server is normally configured to serve static resources (like images and stylesheets) directly.
If the URL does not match a static resource, the web server sends it to the Rails application for handling. The exact mechanism for doing this depends on both the specific web server and interface protocol that the Rails application is using (CGI, FCGI, SCGI, and so on).
Once the request gets delivered to the Rails application, regardless of the delivery mechanism, it is handled exactly the same way.
Rails parses the URL to determine the controller, action, and parameters for the request. With Rails routing, parts of the URL can specify additional parameters, and the entire routing process is under your control. Routing rules work the same on any web server because Rails controls all URL processing with the code in config/routes.rb , without relying on the web server.
The default routing (if you don't modify the routing rules) is http:// <base-url>/<controller>/<action>/<id> . So a URL like http://www.coolsite.com/product/order/23 calls the order method (the action) in the ProductsController class (the controller) with an id parameter set to the value 23 .
The router calls the target action method in the target controller. The action method retrieves any needed data from any business logic in Active Record models, Action Web Services, or other backend APIs. The action method then assigns that incoming data to instance variables (like @accounts or @order ). Rails automatically makes any instance variables created in the action method available to the views.
The action method either lets the default view template render the response, specifies a view template to render, or redirects the response to another URL. Most commonly, the action renders the default view template, which has the same name as the action.
Rails renders a view template to create the HTML response text that is sent back to the browser. A view template may generate the entire HTML response, but more likely is that the controller will have specified a layout template that is rendered first, with the contents of the view template being inserted into the layout. Layouts make it easy to include headers, footers, and other content that should appear on every page.
The view template can also cause other small templates, called partials , to be rendered and inserted into the view template's output. This approach is great for rendering elements than are used on more than one page or multiple times on a single page because the code won't have to be duplicated .
After combining the rendered output of the layout, view template, and any partials invoked by the view template, the resulting HTML response text is sent back to the browser.

Figure 5-1 shows how Rails handles an HTTP request.

Figure 5-1. Handling an HTTP request

This chapter touches briefly on routing, but focuses on Steps 6 through 10. Later, we'll introduce Ajax, a richer model for building web-based user interfaces. The Ajax model will change this flow, but not by much. First, let's work on those features of Photo Share that need attention.