current child index on fields_for nested attributes

Patch looks useful, but a couple formatting notes:

• It's hard to tell what this patch does, as it's got several commits in it. You'll want to format it as a single commit for inclusion in Rails.

• Don't reformat existing code; it makes the changelog noisy and doesn't serve a purpose. I'm specifically referencing the blank lines after 'def foo_bar(x,y,z)'.

• Similarly, blank lines shouldn't have spaces - especially not lines that were really blank before (just \n) and are now "\n ". It's always good to turn on visible newlines (or equivalent in your editor) and make sure that there's not trailing whitespace.

Thanks for contributing!

Well, Pratik and i talked and he suggested a totally different way to solve this issue, fields_for_with_index.

As far as i am concerned, this patch is invalid :), i'll format a new one (better formatted too e.g) in the next couple of days.

Ok, this patch makes more sense.

I've added FormHelper#fields_for_with_index and some tests (duplicates of some fields_for tests).

Going through the entire fields_for cycle, i found that it was really integrated with the entire process of rendering a form, more specifically fields_for_with_index_nested_model. i chose to duplicate the entire method chain of fields_for to match the fields_for_with_index need in a second block parameter ( |builder, index| ) mainly because i didn't find a better way to patch the existing code to consider that, and @Matt's 2nd note "don't reformat existing code"

this patch is useful!
in the mean time (on 2.3.2) I use a wrong/bad/ridiculous solution :)

<% f.fields_for :emails do |email_fields| %>

<%= email_fields.text_field :address %>

<% end %>

email_fields.object_name.gsub(/[^0-9]+/,'') => actual fields_for index!

so....

uahhhh! yes! we can! :P

+1 for this too

+1 for this. It'll make it much easier to add new nested objects dynamically.