Question

tl;dr: It seems like params[:commit] does not contain the actual relevant information to create a new Commit, instead, it only contains the value of the submit button for the form whose name is also “commit”. Any ideas as to why this is happening? I did not change anything.

I am running rails 3 with the webrick server since it displays relevant debugging information. I created a model with only one attribute, description:text, and everything seems to be working fine.

However, when I go to create a new one using the auto-generated scaffolding form, it does not seem to care about the description text-area value. In other words, after having been created, the created_at column is fine and all but the description does not show up at all. Here is the output from the server:

Started POST "/commits" for 127.0.0.1 at 2010-11-03 17:24:20 -0700
Processing by CommitsController#create as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"F00A8Ttv7ceREegfZmP+T5kr+6u2YbRJrQzmfEOaT7o=", "commit"=>"Create Commit"}
SQL (0.5ms)  INSERT INTO "commits" ("created_at", "description", "updated_at") VALUES ('2010-11-04 00:24:20.986571', NULL, '2010-11-04 00:24:20.986571')
Redirected to http://0.0.0.0:3000/commits/5
Completed 302 Found in 42ms

Here is what my migration looks like, auto-generated by rails generate

def self.up
  create_table :commits do |t|
    t.text :description

    t.timestamps
  end
end

So as you can see, it is seeing the description value as NULL even though I did type something into the text area. Here is what rails generated in the _form.html.erb partial:

<div class="field">
  <%= f.label :description %><br />
  <%= f.text_area :description %>
</div>

Anyone have any ideas as to why this is happening? I’m pretty sure it’s some obvious thing too.

By the way, rails console works fine when I create one and save it manually, so I have a feeling there is a disconnect going on in the controller when it goes to save or something.

EDIT: I noticed something interesting. In the controller, the object is created as such:

@commit = Commit.new(params[:commit])

However, as noted in the webrick output above, the parameters the server receives are only:

Parameters: {"utf8"=>"✓", "authenticity_token"=>"F00A8Ttv7ceREegfZmP+T5kr+6u2YbRJrQzmfEOaT7o=", "commit"=>"Create Commit"}

So it doesn’t seem like it gets the description parameter, which I imagine should have been wrapped in the commit parameter, but then if I look at the source for the new form, it shows that the description’s text area is of name commit[description], but the submit button is of name commit. So somehow it’s getting only the value of the submit button, which is indeed of value “Create Commit”, and not the other information it requires.

I don’t know that much about rails though so I don’t really know if this is the case or what.

Someone please help me out haha.

EDIT: Here is the rest of the _form.html.erb partial generated by rails. Perhaps you can spot the glaring issue:

<%= form_for(@commit) do |f| %>
  <% if @commit.errors.any? %>
    <div id="error_explanation">
      <h2><%= pluralize(@commit.errors.count, "error") %> prohibited this commit from being saved:</h2>

      <ul>
      <% @commit.errors.full_messages.each do |msg| %>
        <li><%= msg %></li>
      <% end %>
      </ul>
    </div>
  <% end %>

  <div class="field">
    <%= f.label :description %><br />
    <%= f.text_area :description %>
  </div>
  <div class="actions">
    <%= f.submit %>
  </div>
<% end %>

Answer: It seems that Rails 3 now automatically gives every submit button a name of “commit”, which conflicts with the name of my model. I feared as much. I’m wondering if there are any further implications on using this name. This problem was solved by explicitly changing the submit call to:

f.submit "Button Text", :name => "something_else"

Answer 1

By default, the rails scaffolding will create a form that will look something like the following:

<%= form_for @commit do |f| %>
  <%= f.label :description %>
  <%= f.text_area :description %>
  <%= submit_tag "Create" %>
<% end %>

Please note that I have collapsed the content of the partial into the form itself. The important thing to understand is what HTML is generated when this happens. It will look like this:

<form action="/commits/create" method="post">
  <label for="commit_description">Description:</label>
  <textarea id="commit_description" name="commit[description]"></textarea>
  <input name="commit" type="submit" value="Create" />
</form>

The gotcha you’ve run into is a name collision between the submit button’s name and the object’s name. Normally, when rails encounters a form name like “commit[description]” it will store the results in @params so the value looks like this:

@params[:commit] = { :description => 'value' }

In fact, that is what rails did. The problem was that the default name generated by the “submit_tag” form helper is also named “commit”. So when rails encountered that form parameter it overwrote the results of the form like this:

@params[:commit] = "Create" # same name as the value of the submit button

To get around this name collision you have a couple options. The first option is to hand write your submit button in plain old HTML. Sure you lose some of the options, but at least you can change the name of the submit button to something else:

<input type="submit" name="who_cares" value="Create Commit" />

The other option is to use a variation of the ‘form_for’ helper. In this case the form’s opening line would look like this:

<%= form_for :newcommit, @commit, :url => { :action => "create" } do |f| %>
  <%= f.label :description %>
  <%= f.text_area :description %>
  <%= submit_tag "Create" %>
<% end %>

That will change the resulting HTML to look like this:

<form action="/commits/create" method="post">
  <label for="newcommit_description">Description:</label>
  <textarea id="newcommit_description" name="newcommit[description]"></textarea>
  <input name="commit" type="submit" value="Create" />
</form>

That will bind your form data to the @params[:newcommit] parameter, and you can continue processing as per normal.

For your further reading enjoyment:

http://guides.rubyonrails.org/form_helpers.html