Rails Action Controller
(Page 1 of 4 )
The Rails Action Controller does what you would expect from the name: it receives a request and then decides what action will handle it. This article, the first of a four-part series, introduces you to the Action Controller. It is excerpted from chapter four of the
Rails Cookbook, written by Rob Orsini (O'Reilly, 2007; ISBN: 0596527314). Copyright © 2007 O'Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O'Reilly Media.
In the Rails architecture, Action Controller receives incoming requests and hands off each request to a particular action. Action Controller is tightly integrated with Action View; together they form Action Pack.
Action Controllers, or just “controllers,” are classes that inherit from ActionController::Base. These classes define the application’s business logic. A real estate web application might have one controller that handles searchable housing listings, and another controller devoted to administration of the site. In this way, controllers are grouped according to the data they operate on. Controllers often correspond to the model that they primarily operate on, although this doesn’t have to be the case.
A controller is made up of actions, which are the public methods of a controller class. To process incoming requests, Action Controller includes a routing module that maps URLs to specific actions. By default, a request to http://railsur1.com/rental/listing/23 tries to invoke the listing action of the RentalController controller, passing in an id of 23. As with much of the Rails framework, if this behavior doesn’t fit your application’s requirements, it’s easy to configure something different.
After Action Controller has determined which action should handle the incoming request, the action gets to perform its task: for example, updating the domain model based on the parameters in the request object. When the action has finished, Rails usually attempts to render a view template with the same name as that action. There are several ways this normal process can be altered, though; an action can redirect to other actions, or it can request that a specific view be rendered. Eventually, a template or some form of output is rendered, completing the request cycle.
Understanding that business logic belongs in the controller rather than in the view and that domain logic should be separated into the model, is the key to maximizing the benefits of the MVC design pattern. Follow this pattern, and your applications will be easier to understand, maintain, and extend.
Next: 4.1 Accessing Form Data from a Controller >>
More Ruby-on-Rails Articles
More By O'Reilly Media
|
 This article is excerpted from chapter four of the Rails Cookbook. written by Rob Orsini (O'Reilly, 2007; ISBN: 0596527314). Check it out today at your favorite bookstore. Buy this book now.
|
|
