Rails 2.0 vs. custom routes

In previous Rails, I used to use these (for example)


Now in Rails 2.0, I believe I am supposed to use these


Am I correct?

But somehow, when I try /users/expand_all, accessing action show with
:id => “expand_all” rather than accessing action expand_all

Is there something in my routes.rb that must be reconfigured?

Check out the new ‘rake routes’ command. It’ll show you what available
routes and helpers you have. Also, check out this sweet cheatsheet:

Your route should look something like this:
map.resources :users, :collection => { :expand_all => :get }

And, from your view, you should be doing something like this (assuming
you’ve defined “expand_all” as a collection route as opposed to a
singular route):

<%= link_to ''Expand All Users", expand_all_users_path %>

If you’ve defined your “expand_all” route as singular, then I’d expect
to see behavior similar to what you’re seeing. If you can’t get it
working, post your routes.rb file here.

On Dec 26, 9:52 am, Sharkie L. <rails-mailing-l…@andreas-

I looked at the cheatsheet. In fact it refers to previous versions of
Rails, and not Rails 2.0.

map.resources :users,
:collection => {
:expand_all => :get

map.resources :users,
:member => {
:say_hello => :get

Install the default route as the lowest priority.

map.connect ‘:controller/:action/:id’

However when I call /users/expand all, it routes to :controller =>
users_controller, :action => show, :id => “expand_all” which is wrong.

rake routes on the other hand reports the correct routing.

I just tried it. Same problem still :frowning:

Ah, there’s the problem.

Try this:

map.resources :users,
:collection => {
:expand_all => :get
:member => {
:say_hello => :get

By calling map.resources twice, you’re overriding the first one. You
have to map each resource as a single call.

On Dec 26, 10:45 am, Sharkie L. <rails-mailing-l…@andreas-

Got it to work now. Thanks!

I find the RESTful routing very confusing for anything other than the
CRUD mode. I can see how GET/PUT/POST/DELETE maps to the controller for
that. Its been soooooo well documented and soooooo many examples; I’m
almost sick of it.

But many of us aren’t doing the kind of model that is in AWDWR, the
catalogue/invoice type of thing.

There’s a whole class of applications that have a very different front
end" Wikis, Games and so forth. Essentially they have one UI because
there is only the one conceptual model that that the user sees. (The
AWDWR has a catalogue view, a invoice view …).

Something like Instiki has 26 public methods - that is things that can
appear as URLs in buttons. Not all of them fit very obviously into the
GPPD approach.

I can squint hard and treat the various print and RSS/Atom as special
cases of ‘view’, all I’ve really done, as far as I can see, is made my
menu button code more complicated.

Instiki also has one shortcoming that is easy to get around. Its urls
are of the form
to point to the wiki controller.
For many domains this is unacceptable. Yes, I know it can be cleaned up
with Apache mod_rewrite, but many of us use hosted services and would
rather do it with the application - in routes.

So would those Rails-ists experienced in resourceful techniques please
help out the rest of us and come up with examples and illustrations that
are a little different, that aren’t in the CRUD model, that don’t
require the name of the controller in the URL to do a 1:1 mapping

Please, lets see some flexibility rather than the same old same old
being repeated. Those who do want the CRUD mode - well there’s plenty
out there on the 'Net right now, you don’t need to add to it with “me
too” postings.

Over the last few centuries, mathematicians have demonstrated
a remarkable tendency to underestimate the cryptanalytic powers
of blunt and heavy objects.
– Jamie Reid, CISSP

Btw, everything in that cheatsheet applies to Rails 2.0.

On Dec 26, 10:47 am, Sharkie L. <rails-mailing-l…@andreas-

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs