This project is archived and is in readonly mode.

#3226 ✓wontfix
Stephen Blackstone

[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

    Stephen Blackstone September 18th, 2009 @ 03:56 PM

    Recreated same patch using git master instead of manually diffing rails 2.3.4

  • JasonKing

    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
  • Stephen Blackstone

    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

    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.

  • Gaius Centus Novus

    Gaius Centus Novus September 27th, 2009 @ 10:44 PM

    -1 I agree with Mike Enriquez

  • CancelProfileIsBroken

    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>

Attachments

Pages