Routing the Rails Way
- The Two Purposes of Routing
- Bound Parameters
- Wildcard Components ("Receptors")
- Static Strings
- The routes.rb File
- The Ante-Default Route and respond_to
- The Empty Route
- Writing Custom Routes
- Using Static Strings
- Using Your Own "Receptors"
- A Note on Route Order
- Using Regular Expressions in Routes
- Default Parameters and the url_for Method
- Using Literal URLs
- Route Globbing
- Globbing Key-Value Pairs
- Named Routes
- What to Name Your Routes
- The Special Scope Method with_options
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
- I dreamed a thousand new paths. . . I woke and walked my old one.
- —Chinese proverb
The routing system in Rails is the system that examines the URL of an incoming request and determines what action should be taken by the application. And it does a good bit more than that. Rails routing can be a bit of a tough nut to crack. But it turns out that most of the toughness resides in a small number of concepts. After you've got a handle on those, the rest falls into place nicely.
This chapter will introduce you to the principal techniques for defining and manipulating routes. The next chapter will build on this knowledge to explore the facilities Rails offers in support of writing applications that comply with the principles of Representational State Transfer (REST). As you'll see, those facilities can be of tremendous use to you even if you're not planning to scale the heights of REST theorization.
Many of the examples in these two chapters are based on a small auction application. The examples are kept simple enough that they should be comprehensible on their own. The basic idea is that there are auctions; each auction involves auctioning off an item; there are users; and users submit bids. That's most of it.
The triggering of a controller action is the main event in the life cycle of a connection to a Rails application. So it makes sense that the process by which Rails determines which controller and which action to execute must be very important. That process is embodied in the routing system.
The routing system maps URLs to actions. It does this by applying rules—rules that you specify, using Ruby commands, in the configuration file config/routes.rb. If you don't override the file's default rules, you'll get some reasonable behavior. But it doesn't take much work to write some custom rules and reap the benefits of the flexibility of the routing system.
Moreover, the routing system actually does two things: It maps requests to actions, and it writes URLs for you for use as arguments to methods like link_to, redirect_to, and form_tag. The routing system knows how to turn a visitor's request URL into a controller/action sequence. It also knows how to manufacture URL strings based on your specifications.
When you do this:
<%= link_to "Items", :controller => "items", :action => "list" %>
the routing system provides the following URL to the link_to helper:
http://localhost:3000/items/list
The routing system is thus a powerful, two-way routing complex. It recognizes URLs, routing them appropriately; and it generates URLs, using the routing rules as a template or blueprint for the generated string. We'll keep an eye on both of these important purposes of the routing system as we proceed.
The Two Purposes of Routing
Recognizing URLs is useful because it's how your application decides what it's supposed to do when a particular request comes in:
|
http://localhost:3000/myrecipes/apples |
What do we do now?! |
Generating URLs is useful because it allows you to use relatively high-level syntax in your view templates and controllers when you need to insert a URL—so you don't have to do this:
<a href="http://localhost:3000/myrecipes/apples">My Apple Recipes</a> Not much fun having to type this out by hand!
The routing system deals with both of these issues: how to interpret (recognize) a request URL and how to write (generate) a URL. It performs both of these functions based on rules that you provide. The rules are inserted into the file config/routes.rb, using a special syntax. (Actually it's just Ruby program code, but it uses special methods and parameters.)
Each rule—or, to use the more common term, simply each route—includes a pattern string, which will be used both as a template for matching URLs and as a blueprint for writing them. The pattern string contains a mixture of static substrings, forward slashes (it's mimicking URL syntax), and wildcard positional parameters that serve as "receptors" for corresponding values in a URL, for purposes of both recognition and generation.
A route can also include one or more bound parameters, in form of key/value pairs in a hash. The fate of these key/value pairs depends on what the key is. A couple of keys (:controller and :action) are "magic," and determine what's actually going to happen. Other keys (:blah, :whatever, etc.) get stashed for future reference.
Putting some flesh on the bones of this description, here's a sample route, related to the preceding examples:
map.connect 'myrecipes/:ingredient',
:controller => "recipes",
:action => "show"
In this example, you can see:
- A static string (myrecipes)
- A wildcard URL component (:ingredient)
- Bound parameters (:controller => "recipes", :action => "show")
Routes have a pretty rich syntax—this one isn't by any means the most complex (nor the most simple)—because they have to do so much. A single route, like the one in this example, has to provide enough information both to match an existing URL and to manufacture a new one. The route syntax is engineered to address both of these processes.
It's actually not hard to grasp, if you take each type of field in turn. We'll do a run-through using the "ingredient" route. Don't worry if it doesn't all sink in the first time through. We'll be unpacking and expanding on the techniques and details throughout the chapter.
As we go through the route anatomy, we'll look at the role of each part in both URL recognition and URL generation. Keep in mind that this is just an introductory example. You can do lots of different things with routes, but examining this example will give you a good start in seeing how it all works.