Forum: Ruby on Rails Use of button_to to access action "new"

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
MarkMT (Guest)
on 2008-10-16 22:48
(Received via mailing list)
I have a question about what is regarded as good practice in the
context of RESTful Rails interfaces.

I have a Subscribers Controller with "index" and "new" (and other)
actions. In routes.rb I define resource-based routing with
"map.resources :subscribers".

In my index view I have a button_to that points to
"new_subscriber_path". Since the button generates a POST request,
which doesn't match any resource-based routes, I also have
"map.connect ':controller/:action'" in routes.rb to ensure that the
request goes to the intended "new"action.

This does exactly what I want it to, but it seems a little awkward to
have defined RESTful routes, and in this particular case to not use
one because of a UI design choice I've made (a button instead of a
link). Should this be viewed as a limitation in the way Rails supports
REST, or is there a different way I should be doing this?

Mark.
August L. (Guest)
on 2008-10-17 00:24
MarkMT wrote:
> In my index view I have a button_to that points to
> "new_subscriber_path". Since the button generates a POST request,
> which doesn't match any resource-based routes, I also have
> "map.connect ':controller/:action'" in routes.rb to ensure that the
> request goes to the intended "new"action.

button_to creates a form, and forms can GET. That is in fact what forms
do by default, but rails specifies that they should be POST because
that's what most people probably want. Anyway, button_to "Foo",
bar_path, :method => :get is the way to go, rather than adding routes
like that.
MarkMT (Guest)
on 2008-10-17 01:19
(Received via mailing list)
Thank you! Just what I needed to know!

Mark.


On Oct 16, 3:24 pm, August L. <removed_email_address@domain.invalid>
This topic is locked and can not be replied to.