This project is archived and is in readonly mode.
[PATCH] form_for for new objects with :index set
Reported by Stephen Blackstone | September 17th, 2009 @ 07:59 PM
If you have multiple forms for new objects of the same object type in a template, currently rails will create multiple form tags with the same DOM id which is clearly syntactically invalid HTML.
Example:
form_for(@post, :index => 5)
form_for(@post, :index => 6)
Current Behavior:
<form class="new_post" action="/posts" method="post"
id="new_post"></form>
<form
class="new_post" action="/posts" method="post"
id="new_post"></form>
New Behavior:
<form class="new_post" action="/posts" method="post"
id="new_post_5"></form>
<form
class="new_post" action="/posts" method="post"
id="new_post_6"></form>
When no index is passed it defaults back to the original behavior.
This patch modifies form_helper.rb and includes a new test in form_helper_test.rb to cover this case.
Cheers,
Stephen Blackstone
Comments and changes to this ticket
-
Stephen Blackstone September 18th, 2009 @ 03:56 PM
Recreated same patch using git master instead of manually diffing rails 2.3.4
-
JasonKing September 18th, 2009 @ 05:43 PM
As mentioned in the core mailing list...
I wonder if there's room in your patch for something feeding automatically from the object? As well as having the explicit option with the
:index
value, perhaps you could also accept:index => true
and use.to_param
of the object in question in that case? -
CancelProfileIsBroken September 25th, 2009 @ 12:02 PM
- Tag set to bugmash
-
Stephen Blackstone September 27th, 2009 @ 04:27 PM
Just to keep everything together - the conversation from this ticket went on on [Rails Core]....
Stephen Wrote:
"I'm not sure about passing :index => true since form_for passes along the value of index to fields_for... It seems like this is already the case for forms when the object is not a new object, i.e.
form_for(@user) ..... etc
yields
the only case where we seem to end up with an ambiguous form tag is multiple forms to create the same object type.."
and then Jason replied back:
Yes, of course, you're right. I had been thinking of the edit scenario in fields_for (which I think would be cool if it did what I suggested when passed true). The excitement of the coincidence confused me, and I didn't really read properly that you were talking about new objects.
+1 on your patch. It makes sense to be consistent between that and what is already done in tags.
-
Mike Enriquez September 27th, 2009 @ 08:26 PM
-1 The same result can be accomplished by doing
form_for(@post, :html => { :id => "new_post_6" })
The patch provides a cleaner syntax, but I don't think it is common enough to be included into core.
-
CancelProfileIsBroken September 28th, 2009 @ 01:32 AM
- Tag cleared.
- State changed from new to wontfix
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>