- 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
Named Routes
The topic of named routes almost deserves a chapter of its own. What you learn here will feed directly into our examination of REST-related routing in Chapter 4.
The idea of naming a route is basically to make life easier on you, the programmer. There are no outwardly visible effects as far as the application is concerned. When you name a route, a new method gets defined for use in your controllers and views; the method is called name_url (with name being the name you gave the route), and calling the method, with appropriate arguments, results in a URL being generated for the route. In addition, a method called name_path also gets created; this method generates just the path part of the URL, without the protocol and host components.
Creating a Named Route
The way you name a route is by calling a method on your mapper object with the name you want to use, instead of the usual connect:
map.help 'help', :controller => "main", :action => "show_help"
In this example, you'll get methods called help_url and help_path, which you can use wherever Rails expects a URL or URL components:
<%= link_to "Help!", help_path %>
And, of course, the usual recognition and generation rules are in effect. The pattern string consists of just the static string component "help". Therefore, the path you'll see in the hyperlink will be
/help
When someone clicks on the link, the show_help action of the main controller will be invoked.
The Question of Using name_path Versus name_url
When you create a named route, you're actually creating at least two route helper methods. In the preceding example, those two methods are help_url and help_path. The difference is that the _url method generates an entire URL, including protocol and domain, whereas the _path method generates just the path part (sometimes referred to as a relative path).
According to the HTTP spec, redirects should specify a URI, which can be interpreted (by some people) to mean a fully-qualified URL2. Therefore, if you want to be pedantic about it, you probably should always use the _url version when you use a named route as an argument to redirect_to in your controller code.
The redirect_to method seems to work perfectly with the relative paths generated by _path helpers, which makes arguments about the matter kind of pointless. In fact, other than redirects, permalinks, and a handful of other edge cases, it's the Rails way to use _path instead of _url. It produces a shorter string and the user agent (browser or otherwise) should be able to infer the fully qualified URL whenever it needs to do so, based on the HTTP headers of the request, a base element in the document, or the URL of the request.
As you read this book, and as you examine other code and other examples, the main thing to remember is that help_url and help_path are basically doing the same thing. I tend to use the _url style in general discussions about named route techniques, but to use _path in examples that occur inside view templates (for example, with link_to and form_for). It's mostly a writing-style thing, based on the theory that the URL version is more general and the path version more specialized. In any case, it's good to get used to seeing both and getting your brain to view them as very closely connected.
Considerations
Named routes save you some effort when you need a URL generated. A named route zeros in directly on the route you need, bypassing the matching process. That means you don't have to provide as much detail as you otherwise would. You have to provide a value for any wildcard parameter in the route's pattern string, but you don't have to go down the laundry list of hard-coded, bound parameters. The only reason for doing that when you're trying to generate a URL is to steer the routing system to the correct route. But when you use a named route, the system already knows which rule you want to apply, and there is a (slight) corresponding performance boost.