Home arrow Ruby-on-Rails arrow Writing an Action Pack Controller

Writing an Action Pack Controller

In this fourth part of a series on the Action Pack library for Rails focusing on the view and the controller, we'll start writing some real code for an Action Pack controller. 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).

Author Info:
By: Apress Publishing
Rating: 5 stars5 stars5 stars5 stars5 stars / 3
March 01, 2011
  1. · Writing an Action Pack Controller
  2. · Named Routes

print this article

Writing an Action Pack Controller
(Page 1 of 2 )

A Controller Walk-Through

Instead of boring you with more theory about controllers, views, and MVC, we think it’s best to dig right in and start writing some real-world code. We’re going to continue building our events application, highlighting the finer points and describing the places where convention wins out over configuration. Along the way, we’ll touch on some of the most essential controller and view concepts. By the end of this walk-through, you’ll have a complete grasp of how the Rails request cycle works, and you’ll have a working example to refer to and expand on in the subsequent chapters. The purpose of this walk-through is not to examine each and every aspect of Action Pack in detail, but rather to give you a practical overview of how the components—routes, controllers, helpers, views, layouts, and partials—work together to control your application and construct its interface.

Setting Up Routes

Links and URLs are important in web applications. They serve as the entry point to the application and contain all the information required to route an incoming request to the controller and action that will handle it. Before we get into the meat of creating controllers and defining actions, we need to spend a few minutes talking about how we get from request to response. As we explained earlier, it all starts with routing.

Routing Basics

In Rails, all the rules for mapping URLs to controllers are a matter of configuration. You’ll find theroutes.rbfile in theconfigdirectory. If you open that file in your editor now and examine it, you’ll see the default route defined last. We’ve already introduced it, but it bears repeating:

map.connect ':controller/:action/:id'

Routes work based on pattern matching and can include variables to set directly within the pattern. Here, the pattern is a three-segment string partitioned by slashes (/) and containing variables to set, where the variables are prefixed by a colon (:). The first segment sets the:controllervariable, the second the:actionvariable, and the third the:idvariable. These variables will be used to determine the controller and action to invoke, and the parameters to send along. The pattern is matched from left to right, and the variables are optional. If the:idvariable is empty, only the controller and action will be set. If the:actionvariable is empty, only the:controllervariable will be set, and so on.

Routing priority is based on the order in which routes exist inroutes.rb, so that the first route defined has the highest priority. If an incoming URL matches the first route defined, the request will be sent along and no other routes will be examined. It’s for this reason that we place the default route last.

Routes are defined using theconnect method. The first argument toconnectis the pattern to match. The second argument is the request parameters to initialize in the form of a Ruby hash.

Here’s an example where we’re matching a specific pattern and setting a hash of parameters in response:

map.connect '/albums/list', :controller => 'albums', :action => 'list'

This route will match a URL likehttp://example.com/albums/listand route the request to thelistaction on thealbumscontroller. We can also set arbitrary parameters when using the route. For example, let’s say we wanted to set a parameter calledquery that we could access and use in our controller.

map.connect '/products/search/:query',
  :controller => 'products', :action => 'search'

This route will match a URL likehttp://example.com/products/search/ipod, routing the request to theproductscontroller and thesearchaction. The third segment in the URL will be assigned to the:queryparameter because we specified:queryas an in-line variable.

Routes can get quite complex, and it’s possible to apply conditions and other forms of logic to them. For the most part though, you’ll get a lot of mileage from the general cases we’ve outlined here. The Rails API documentation (http://api.rubyonrails.org/ classes/ActionController/Routing.html) contains details on using the more complex routing features.

blog comments powered by Disqus

- Ruby-on-Rails Faces Second Security Flaw in ...
- Ruby 2.0 Prepped for February 2013 Release
- Why LinkedIn Switched from Ruby on Rails
- Adding Style with Action Pack
- Handling HTML in Templates with Action Pack
- Filters, Controllers and Helpers in Action P...
- Action Pack and Controller Filters
- Action Pack Categories and Events
- Logging Out, Events and Templates with Actio...
- Action Pack Sessions and Architecture
- More on Action Pack Partial Templates
- Action Pack Partial Templates
- Displaying Error Messages with the Action Pa...
- Action Pack Request Parameters
- Creating an Action Pack Registration Form

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2019 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials