Renaming routes in Rails 2.* is straight forward. It goes something like this.

## config/routes.rb
map.resources :users, :as => :members

This will give you users_path and form_for(User.new) helpers, for instance, mapping the url to /members instead of /users while using the users_controller.rb class.

In Rails 3.*, this is still possible. It is accomplished differently. In my opinion, it seems a little less elegant.

# config/routes.rb
resources :members, :as => :users, :controller => :users
# app/views/**/*.erb
link_to "Members", users_path
form_for User.new do |f|
# Rake routes
       users GET    /members(.:format)           {:controller=>"users", :action=>"index"}
       users POST   /members(.:format)           {:controller=>"users", :action=>"create"}
    new_user GET    /members/new(.:format)       {:controller=>"users", :action=>"new"}
   edit_user GET    /members/:id/edit(.:format)  {:controller=>"users", :action=>"edit"}
        user GET    /members/:id(.:format)       {:controller=>"users", :action=>"show"}
        user PUT    /members/:id(.:format)       {:controller=>"users", :action=>"update"}
        user DELETE /members/:id(.:format)       {:controller=>"users", :action=>"destroy"}

Your resource is “members” and you are overriding the name (using :as=>”users”) however, you still have to specify the controller.

http://pastie.org/1154956

There are a few things that need to be taken care of before you can get this to work. The first thing (although, any of the following steps can be done in any order) to take care of involves your User model. You need to override the to_param method, so that Rails will appropriately use the username attribute rather than user_id when constructing paths.

#in app/models/user.rb
def to_param
  "#{self.username}"
end

Next we move onto routing our resources. Here it gets a little tricky because Rails is building paths for us. Remeber, you can get a list of all currently defined routes in your application by running the routes rake task

rake routes

We need to set the path_prefix option on any of our resources we want scoped by the username. For instance, in this example, I have set up a Status model and statuses_controller, whose urls shall be scoped by the username. You can apply the path_prefix to any number of other resources in your routes config file. They symbol used is arbitrary, but will be made available in the params hash, in this case params[:user_id]. You also need to exclude the show action on your users resources declaration. The reason is that, otherwise, Rails will include the controller name in the path like /users/username, which doesn’t look as clean as just /username. You then need to redefine this route explicitly (last line in the routes config shown here).

#in app/config/routes.rb
map.resources :statuses,   :path_prefix => '/:user_id'
map.resources :users,     :except => [:show]
map.user '/:username' :controller => 'users', :action => 'show'

Finally, you get to call these routes in your views or use them in your controllers. You use the same link_to, url_for methods to generate paths. When constructing the resources you have setup with the path_prefix declartion, remember you need the user model as the first argument, followed by said resource.

<%= link_to(status.title, status_path(status.user,status) %>
# or in a controller
redirect_to status_path( status.user, status )

That’s pretty much it. If anyone has another way of doing this let me know!

The will_paginate plugin for Rails uses a key/value assignment like ?page=2, rather than the pretty url formats such as /page/2 … This is because url generation and mapping are handled by the routes.rb file. You’ll need to modify the file so that rails knows what to do with request that match the pattern. Make sure to put the custom (map.connect) route before the normal restful routes (map.resources)

map.connect '/topics/:id/page/:page', :controller => 'topics', :action => 'show'
map.resources :topics

Internally will_paginate uses the url_for method so Rails will now know how to construct your urls in a pretty way. I got most of this info from this discusson http://groups.google.com/group/will_paginate/browse_thread/thread/d0142b512cfca9d5?pli=1

There is nothing wrong leaving the default behavior alone and looking at the ‘ugly’ key/value pairs in the address bar. However, if you take advantage of page caching in rails, you’ll need to do this anyway. Page caching in rails ignore extra parameters, any info before/after the “?” and “&” symbols. There will be no difference from /topics/2?page=1 and /topics/2?page=100 in your cache. And since most likely the content will be very different on these two pages, you’ll need to have pretty urls so that page caching will save topics/2/page/1.html and topics/2/page/100.html as two different resources!

With namespace routes in Rails you can easily create a prefix for select resources. For instance, if you have an admin area or an account dashboard you can give logged in users access to methods that are not otherwise available. To use namespaces define them in config/routes.rb. *Note: this is available for the latest release of Rails, at this time it is 2.3.0. I think it’s supported back until Rails 2.0, but haven’t tested it.

In your config/routes.rb file

map.namespace :dashboard do |dashboard|
    dashboard.resources :properties, :collection=>{:available => :get}
end

This namespace will create routes such as dashboard/properties, dashboard/properties/1, essentially all the CRUD paths as well as a collection method “available” dashboard/properties/available. These routes can be accessed in your views with methods such as new_dashboard_property_path, available_dashboard_properties_path  etc. If your property model has it’s own controller that isn’t namespaced, properties_controller.rb, remember to modify the property form_for method to tell it to use the dashboard namespace. The normal form_for(@property), method takes just your property object. Instead pass the dashboard symbol inside of an array  to form_for

<% form_for [:dashboard, @property] do |f| %><% end %>

You can easily see all of the available paths from the command line using rake routes. I use grep to filter the results for conveinence, because on a large application I don’t necessarily need to see all the routes if I’m working just within a single namespace. rake routes | grep dashboard