In this third part of an article series on the Action Pack library for Rails, you'll learn about the specialized Action Pack component called routing, and the basic steps of the Action Pack request cycle. This article is excerpted from chapter six of the book Beginning Rails: From Novice to Professional, written by Jeffery Allan Hardy, Cloves Carneiro Jr. and Hampton Catlin (Apress; ISBN: 1590596862).
Action Pack Routing and Request Cycle - The Action Pack Request Cycle (Page 2 of 2 )
We refer to the entire request-to-response process as the Action Pack request cycle. The request cycle consists of the following steps:
Rails receives a request from the outside world (usually a browser).
Routing picks apart the request to determine the controller and action to invoke.
A new controller object is instantiated and an action method is called.
The controller interacts with the model (usually performing a CRUD operation).
A response is sent back to the browser, either in the form of a render or a redirect.
Figure 6-1 illustrates the process.
Figure 6-1. The Action Pack request cycle
Not too long ago (and to be sure, today still), developers used to construct so-called “server pages.” Such a page would have a bunch of code at the top of an otherwise static page, just above the opening HTML tag. The markup would be littered with all sorts of code, and it wouldn’t be at all unusual to see the database being accessed, forms being processed, sessions being set, and all manner of logic being performed in-line. The web server would be responsible for controlling the application—one page redirecting to another, running the code, and then dumping the results to the screen.
We won’t get into the multitude of reasons why this is a bad idea, except to say that it presents the problem of coupling. In this scenario, the business logic and the view are all mashed together, making things more difficult to maintain and debug. ASP and PHP pages are notable offenders, and if you’re coming from either of these camps, the concept of separating concerns might be foreign at first. Here’s a way to think about it that might help. Imagine taking all that code and logic from the top of each page and sticking it in one place, leaving only the HTML behind. Then instead of using the web server to invoke each page as you would with a static site, have the web server call on a single dispatcher that finds the code you want to execute and calls it. The code it would invoke—the file that contains all your processing logic extracted from the server page—would be called the controller. Instead of dividing logic among “pages,” it would be divided into actions.
The single biggest advantage of this pattern is that the processing logic is decoupled from the view and safely contained in one place. As you’ll see, it’s a lot easier to work this way. The interplay between actions is considerably easier to visualize and understand when it is not spread out over a host of locations. Your server pages become lightweight views, left to handle only the simplest of instructions, if any at all.
Please check back for the next part of the series.
DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.