This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 144892 - Warp to Controller/View from link_to should support Rails 2 named paths
Summary: Warp to Controller/View from link_to should support Rails 2 named paths
Status: NEW
Alias: None
Product: ruby
Classification: Unclassified
Component: Editing (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: issues@ruby
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-22 18:48 UTC by Chris Kutler
Modified: 2011-01-28 20:12 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Kutler 2008-08-22 18:48:17 UTC
Using the old (pre Rails 2) link_to  arguments, you can warp to the action. However, because Rails 2+ is pushing
developers towards using RESTful routes, and the scaffold generator now emits code using <named route>_path or <named
route>_url in the link_to arguments, instead of :controller and :action options. So maybe it would be nice to warp to
controller from the named paths in the link_to calls as well, if possible (it is a bit complex, especially with nested
relations, so it might be too hard).

Instead of

<%= link_to "cancel", :controller => "posts" %>

the generated code is now

<%= link_to "cancel", posts_path %>

The default in Rails 2+ is to not use :action => and :controller => options anymore in link_to calls, but use named
paths or named_urls instead.

If you create a Rails project and use the scaffold generator, and then run the routes rake task, it will show what
action, controller, and HTTP verb gets called for each named route, like what I show below. So, posts_path goes to the
posts controller. It goes to the index action unless the link_to is in a form (the submission passes the POST verb), in
which it goes to the create action. The new_post_path goes to the new action, and the edit_post_path goes to the edit
action. It gets trickier with master-detail relationships (see http://www.netbeans.org/kb/61/ruby/model.html#04a)

              posts GET    /posts                           {:controller=>"posts", :action=>"index"}
    formatted_posts GET    /posts.:format                   {:controller=>"posts", :action=>"index"}
                    POST   /posts                           {:controller=>"posts", :action=>"create"}
                    POST   /posts.:format                   {:controller=>"posts", :action=>"create"}
           new_post GET    /posts/new                       {:controller=>"posts", :action=>"new"}
 formatted_new_post GET    /posts/new.:format               {:controller=>"posts", :action=>"new"}
          edit_post GET    /posts/:id/edit                  {:controller=>"posts", :action=>"edit"}
formatted_edit_post GET    /posts/:id/edit.:format          {:controller=>"posts", :action=>"edit"}
               post GET    /posts/:id                       {:controller=>"posts", :action=>"show"}
     formatted_post GET    /posts/:id.:format               {:controller=>"posts", :action=>"show"}
                    PUT    /posts/:id                       {:controller=>"posts", :action=>"update"}
                    PUT    /posts/:id.:format               {:controller=>"posts", :action=>"update"}
                    DELETE /posts/:id                       {:controller=>"posts", :action=>"destroy"}
                    DELETE /posts/:id.:format               {:controller=>"posts", :action=>"destroy"}
               root        /                                {:controller=>"posts", :action=>"index"}
                           /:controller/:action/:id        
                           /:controller/:action/:id.:format