How to use Rails named route helpers with paramete

问题:

given this route

match 'posts/hello/:name/:title' => 'post#show', :as => :hello

• what are the ways that I can call hello_path ?

• if i call hello_path(@post), what does it try to do?

I was hoping that the :name and :title files will bind to the path automatically but it seems that rails only know how to get the :id out of the model object.

instead, it only works if I call it like

<%= link_to "link2", hello_url(:name=> @post.name, :title=>@post.title) %>

(lack of proper documentation is really killing me)

回答1:

To answer your two questions:

• At the command line, runrake routes to see what routes there are in your app. It will show you all the ways you can use the named routes, just add "_path" or "_url" to the name of the route which is shown on the left.
• Calling hello_path(@post) will generate a URL to the show page for that hello instance.

The way you are calling it is the norm:

<%= link_to "link2", hello_url(:name=> @post.name, :title=>@post.title) %>

However, this may work too:

<%= link_to "link2", hello_url(@post.name, @post.title) %>

Here is some documentation (other than the Rails API) which should help. http://guides.rubyonrails.org/routing.html

回答2:

To answer your question of "what does hello_path try to do?"

hello_path knows how many parameters it's supposed to get. This is from counting the named parameters in config/routes. It will accept either a hash or a list of arguments. If you give it a hash, the keys must match the names of the URL parameters. If you give it a list of arguments, it'll just match them up by position - the first argument with the first named parameter.

Then, it will call to_param on each parameter individually before joining them all together (see code here, 4.0 branch).

If you pass in an object when it's expecting 2 or more params, it won't even get around to calling to_param on the object. That's when you get errors with no stack trace that say something like
No route matches {:controller=>"posts", :action=>"show", :id=>#<Post ...>}

Working with 1 named parameter

If you've only got one named parameter, things are pretty straightforward. If you need to look up your posts by name instead of id, you can just redefine to_param

class Post < ActiveRecord::Base
  ...
  def to_param
    name
  end
end

Working with multiple named parameters

But if the URL has more than one named parameter in it, then redefining to_param isn't enough. Let's say you tried this:

# app/models/post.rb
class Post < ActiveRecord::Base
  ...
  def to_param
    {name: name, title: title}
  end
end

# app/views/posts/index.html.erb
<%= post_path(post) %>

In this case, you'll get a routing error because you're not passing in enough arguments to post_path (see above). To get around this, I just call to_param explicitly:

 # app/views/posts/index.html.erb
 <%= post_path(post.to_param) %>

This is a little less slick than most Rails routing magic, but works perfectly well. If you later change the way you're looking up Posts, all you have to do is redefine to_param. No need to worry about all the places you've called post_path

Under the hood

The relevant code to look at is actionpack/lib/action_dispatch/routing

回答3:

You can also call it like this

hello_path(@post.name, @post.title)

Hope it helps.

回答4:

The other answers (at the time of this writing) are fine, but your reply to GregT's answer shows a lack of understand about Rails, which is fine -- we've all been there.

Specifically, three of the key principles behind Rails: convention over configuration, the model-view-controller architecture (MVC), and REST. It's stuff at the beginning of every beginning Rails book. Beginners often think they can just jump to the first chapter with code, but Rails differs from many other topics in that the first chapters explain important concepts and aren't just intro chapter filler. Because Rails isn't "code", it's a "framework of code".

"Convention over configuration" means if you follow certain conventions then you benefit from behaviors baked into Rails. Routing is one of those areas, if not the biggest, where convention benefits the developer although it is entirely configurable.

Paths following a specific routing format, are parsed into the controller, action and possibly an id, format, and additional parameters. By default and at minimum, a Rails (and also a Sinatra) path takes the following format and order:

/controller_name/action_name

It's a little more complicated than that, with more options, and it looks more like this in actuality:

/controller_name/action_name/(id)(.format)(?param=value)(&...)

...but it's more detail than is necessary for this answer.

The controller is the C in MVC, or the class that handles the request. The action is one of the seven RESTful actions (index, show, new, create, edit, update, and destroy) within that controller. Not all actions require an id (index, new and create) and not all of them are get requests (requests that generate a view, for instance destroy, create and update don't have views).

Putting it all together we see this example:

/articles/edit/1

...will route the request to the 'edit' action in the ArticlesController controller passing along id 1. It's expected that the controller will do some housekeeping, like authentication and authorization, then retrieve Article model (MCV) with ID 1 and pass it along to the "edit" view (MCV).

It's best, especially for new Rails developers, to stick to these conventions and perhaps add a few additional actions beyond those provided by REST.

You can step outside this convention by configuring in your routes.rb file an alternative routing scheme, not following REST, etc., but you'll be like a salmon swimming upstream -- it's a lot harder than going with the flow. If you go down that path (pun) you'll make a lot of additional work for yourself, probably reinvent the wheel somewhat, and lose advantages provided by the Rails framework. If you find yourself in that situation for whatever reason, perhaps Rails isn't the right tool for your job.