Forceing PUST vs. POST in form

rubyonrails-talk
#1

I am experimenting with a combined form. I wish to force the HTTP verb
for this form to PUT. However, it always uses POST when submitted and I
cannot determine why.

The view template code is:

  <%=form_for( @user,
      :html => {
        :class => :edit_user_role,
        :id => :edit_user_role_form,
        :method => :put },
      :url => user_roles_url( @user )

        ) do |f|-%>

The resulting html is:

<form accept-charset="UTF-8"
  action="http://www.example.com/users/330/roles"
  class="edit_user_role"
  id="edit_user_role_form" method="post">
  <div style="margin:0;padding:0;display:inline">
    <input name="utf8" type="hidden" value="&#x2713;" />
    <input name="_method" type="hidden" value="put" />
  </div>

This confuses me. The form method is not being set by the html
attribute but a hidden field is being created instead. Since Rails
considers only the HTTP verb for routing this simply will not work as I
expect.

What is the problem with my approach? How does one set the form method?

#2

James Byrne wrote in post #972875:

I am experimenting with a combined form. I wish to force the HTTP verb
for this form to PUT. However, it always uses POST when submitted and I
cannot determine why.

Because that's the way Rails works. Many browsers don't support PUT
forms, so Rails leaves the method as POST and adds a hidden field to
fake what the method "really" is. Rails does the processing of that
hidden field transparently, so that a POST with method "_put" will
appear to the framework exactly like a real PUT.

Best,

#3

Marnen Laibow-Koser wrote in post #972876:

James Byrne wrote in post #972875:

I am experimenting with a combined form. I wish to force the HTTP verb
for this form to PUT. However, it always uses POST when submitted and I
cannot determine why.

Because that's the way Rails works. Many browsers don't support PUT
forms, so Rails leaves the method as POST and adds a hidden field to
fake what the method "really" is. Rails does the processing of that
hidden field transparently, so that a POST with method "_put" will
appear to the framework exactly like a real PUT.

Then does that mean one must always provide a route for the new method,
even if it makes no sense to do so within a given context?

#4

James Byrne wrote in post #972918:

Marnen Laibow-Koser wrote in post #972876:

James Byrne wrote in post #972875:

I am experimenting with a combined form. I wish to force the HTTP verb
for this form to PUT. However, it always uses POST when submitted and I
cannot determine why.

Because that's the way Rails works. Many browsers don't support PUT
forms, so Rails leaves the method as POST and adds a hidden field to
fake what the method "really" is. Rails does the processing of that
hidden field transparently, so that a POST with method "_put" will
appear to the framework exactly like a real PUT.

Then does that mean one must always provide a route for the new method,
even if it makes no sense to do so within a given context?

I don't understand your question.

Best,

#5

Marnen Laibow-Koser wrote in post #972921:

James Byrne wrote in post #972918:

Then does that mean one must always provide a route for the new method,
even if it makes no sense to do so within a given context?

I don't understand your question.

I get this error when I submit the form.

no route exists for "/users/1/roles"

However, I get to the form via "/users/1/roles/new" called from
"/users/1/role", which is where I want to return to after the update
completes. At the moment I am perplexed by this, to me, mysterious
behaviour and error message.

In other words, I can start by entering
http://localhost:3000/users/1/roles

That URL displays all the roles associated with User.find(1)

From that page I follow a link to
http://localhost:3000/users/1/roles/new
which displays the input form. When I complete and submit the form I
get this error:

No route matches "/users/1/roles"

which is the very URL I have just come from.

#6

James Byrne wrote in post #972930:

Marnen Laibow-Koser wrote in post #972921:

James Byrne wrote in post #972918:

Then does that mean one must always provide a route for the new method,
even if it makes no sense to do so within a given context?

I don't understand your question.

I get this error when I submit the form.

no route exists for "/users/1/roles"

Do you have a route defined with method PUT?

However, I get to the form via "/users/1/roles/new" called from
"/users/1/role",

What do you mean by that? The previous page is irrelevant -- HTTP is
stateless, remember?

So...describe exactly how you get here

which is where I want to return to after the update
completes.

*Which* page is where you want to return to?

What does the controller action look like?

At the moment I am perplexed by this, to me, mysterious
behaviour and error message.

In other words, I can start by entering
http://localhost:3000/users/1/roles

That URL displays all the roles associated with User.find(1)

Right. Standard RESTful nested resources (on GET).

From that page I follow a link to
http://localhost:3000/users/1/roles/new
which displays the input form. When I complete and submit the form I
get this error:

No route matches "/users/1/roles"

which is the very URL I have just come from.

But you came from it as GET, not PUT. Routes include method, not just
URL.

What's your rake routes output like for these paths?

Best,

#7

Marnen Laibow-Koser wrote in post #972933:

But you came from it as GET, not PUT. Routes include method, not just
URL.

I knew that. Nonetheless that is the bit I had confused. I was trying
to override the form method for the right reason but I fixed upon the
wrong method, PUT, instead of GET.

Thank you for the help.

#8

James Byrne wrote in post #972938:

Marnen Laibow-Koser wrote in post #972933:

But you came from it as GET, not PUT. Routes include method, not just
URL.

I knew that. Nonetheless that is the bit I had confused. I was trying
to override the form method for the right reason but I fixed upon the
wrong method, PUT, instead of GET.

Thank you for the help.

You probably don't want the form submission to be GET.

Best,

#9

Marnen Laibow-Koser wrote in post #972943:

You probably don't want the form submission to be GET.

You are probably right. But for now I am simply exploring how things
work for a nested resource. I will rewire the controller when I figure
how what I want each bit to do and how I want it to look.

#10

James Byrne wrote in post #972946:

Marnen Laibow-Koser wrote in post #972943:

You probably don't want the form submission to be GET.

You are probably right. But for now I am simply exploring how things
work for a nested resource. I will rewire the controller when I figure
how what I want each bit to do and how I want it to look.

No! If you need to make the form submission GET, then something is
*badly wrong*. Rails' resource mapping should make the PUT form work by
default. If that isn't working, find out why. Perhaps we should take a
look at your routes.

Best,

#11

Marnen Laibow-Koser wrote in post #972947:

No! If you need to make the form submission GET, then something is
*badly wrong*. Rails' resource mapping should make the PUT form work by
default. If that isn't working, find out why. Perhaps we should take a
look at your routes.

I believe that I know the source of the problem. I have deliberately
created a merged edit/new form and forced the controller to map
different methods to specific templates. I do not intend for this to
remain. But I am interested in seeing what behaviour results.

#12

James Byrne wrote in post #972959:

No! If you need to make the form submission GET, then something is
*badly wrong*. Rails' resource mapping should make the PUT form work by
default. If that isn't working, find out why. Perhaps we should take a
look at your routes.

I believe that I know the source of the problem. I have deliberately
created a merged edit/new form and forced the controller to map
different methods to specific templates. I do not intend for this to
remain. But I am interested in seeing what behaviour results.

It's common to "merge" the new and edit forms. The body of the form goes
into a partial that the two views (new and edit) share. That's the
cleanest and most direct way to accomplish what it sounds like you want.

#13

Interestingly, w3.org indicates that there are only two valid HTTP verbs
for the form and the submit elements. Those are GET and POST.

#14

James Byrne wrote in post #972964:

Interestingly, w3.org indicates that there are only two valid HTTP verbs
for the form and the submit elements. Those are GET and POST.

Exactly. Which is why Rails fakes PUT forms as I explained earlier.
It's a POST as far as the browser is concerned, but a PUT as far as
Rails is concerned.

Best,

#15

Marnen Laibow-Koser wrote in post #972966:

James Byrne wrote in post #972964:

Interestingly, w3.org indicates that there are only two valid HTTP verbs
for the form and the submit elements. Those are GET and POST.

Exactly. Which is why Rails fakes PUT forms as I explained earlier.
It's a POST as far as the browser is concerned, but a PUT as far as
Rails is concerned.

And, if you really, really want to know how and where that happens, that
would be here:

http://guides.rubyonrails.org/v2.3.8/rails_on_rack.html#internal-middleware-stack

Notice: Rack:MethodOveride