I was using form_for to create multiple objects on the same page. All of them were of the same active record class. Even tho I was using index on the form_for, it created several form blocks with the same id new_object_class. This patch adds the _#{index} to the id name if an index is specified…
Examples and patch are in the lighthouse ticket and includes the appropriate test case.
Best Regards, Stephen Blackstone
Ok, this is bizarre timing. I was thinking about this problem last night, and I “dream-coded” that I suffixed ALL id fields with: (object.respond_to?(:to_param) and ( id = object.to_param ) ? "#{_id}" : “” )
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?
Jason
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
<form action="/users/1" class="edit_user" id="edit_user_1"
the only case where we seem to end up with an ambiguous form tag is multiple forms to create the same object type… or am I missing something?
Stephen Blackstone
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.
Keep up to date with Rails on Twitter and This Week in Rails
Policies: Conduct, License, Maintenance, Security, Trademarks