# Form\_for submit ends up in the "index" action

**URL:** <https://www.ruby-forum.com/t/form-for-submit-ends-up-in-the-index-action/143468>\
**Category:** Rails\
**Created:** [July 18, 2008, 11:04pm UTC](https://www.ruby-forum.com/t/form-for-submit-ends-up-in-the-index-action/143468 "2008-07-18T23:04:43Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![markmt](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/df705f/32.png) [@markmt](https://www.ruby-forum.com/u/markmt)\
**Post date:** [July 18, 2008, 11:04pm UTC](https://www.ruby-forum.com/t/form-for-submit-ends-up-in-the-index-action/143468/1 "2008-07-18T23:04:43Z")

</div>

I have a strange bug that’s driving me slightly crazy. Maybe the  
symptoms will be more meaningful to someone else here…

I have a set of REST actions in my controller and a form\_for in both  
my new and edit views, in both cases with fields\_for constructs  
embedded. The models have some validation rules in place.

A successful create action renders the edit view to allow  
modifications to be made the data.

However, if I enter invalid data into some of the embedded fields in  
the form, when I resubmit the form the second time, with either valid  
or invalid data, the browser ends up (apparently) invoking the index  
action and it associated view instead of create. On the face of it it  
kind of looks as if the browser request is coming in as a GET (since  
that would turn a create index into an index), but there’s no obvious  
reason that that should happen for a form, nor any inking in firebug  
that that’s what’s actually happening.

Does this ring any bells with anyone? No doubt something simple, but  
my sleep deprived brain just isn’t seeing it right now.

Thanks for any advice.

Mark.

---

<div class="post-metadata">

**Author:** ![markmt](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/df705f/32.png) [@markmt](https://www.ruby-forum.com/u/markmt)\
**Post date:** [July 20, 2008, 6:21am UTC](https://www.ruby-forum.com/t/form-for-submit-ends-up-in-the-index-action/143468/2 "2008-07-20T06:21:26Z")

</div>

Ok, so this didn’t attract any suggestions, but here fwiw is how I  
solved the problem…

I still don’t know exactly why I was ending up in the index view, but  
it seems that the underlying problem was that when the form was being  
resubmitted after validation failure, Rails was interpreting my  
form\_for as an “edit” form, rather than a “new” form - and  
consequently putting a hidden \_method = put parameter in the form  
markup.

Apparently the reason it was treating this as an “edit” form the  
second time around is that the validation failure was happening in the  
“create” action on the embedded “fields\_for” fields, but this only  
happened after the primary fields for the “form\_for” had already been  
save! 'd. I had the whole thing wrapped in a transaction, which was  
correctly preventing the primary fields from actually making it to the  
db, but the objects themselves were still being treated as if they had  
been saved - even though they hadn’t - and so Rails apparently figured  
that the purpose of the subsequent form was to edit this “existing”  
data.

The solution: in my “create” action, I just moved the save! of the  
primary “form\_for” fields to occur _after_ those embedded in  
“fields\_for” have been save! 'd. This means that if the primary fields  
only ever get created if the embedded fields have successfully  
validated, i.e. the transaction as a whole is good.

MT

---

<div class="post-metadata">

**Author:** ![markmt](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/df705f/32.png) [@markmt](https://www.ruby-forum.com/u/markmt)\
**Post date:** [July 20, 2008, 1:44pm UTC](https://www.ruby-forum.com/t/form-for-submit-ends-up-in-the-index-action/143468/3 "2008-07-20T13:44:07Z")

</div>

Hi –

On Sat, 19 Jul 2008, MarkMT wrote:

> The solution: in my “create” action, I just moved the save! of the  
> primary “form\_for” fields to occur _after_ those embedded in  
> “fields\_for” have been save! 'd. This means that if the primary fields  
> only ever get created if the embedded fields have successfully  
> validated, i.e. the transaction as a whole is good.

You might look into the build method, which lets you create an  
association in memory without saving, and then, assuming the  
validations are in place, it will do an all-or-nothing save. That may  
be a good defense against the (in my view) excessive “magic” of  
form\_for(@object) 🙂

David

–  
Rails training from David A. Black and Ruby Power and Light:  
Intro to Ruby on Rails July 21-24 Edison, NJ  
Advancing With Rails August 18-21 Edison, NJ  
See [http://www.rubypal.com](http://www.rubypal.com) for details and updates!

---

<div class="post-metadata">

**Author:** ![markmt](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/df705f/32.png) [@markmt](https://www.ruby-forum.com/u/markmt)\
**Post date:** [July 21, 2008, 12:27am UTC](https://www.ruby-forum.com/t/form-for-submit-ends-up-in-the-index-action/143468/4 "2008-07-21T00:27:36Z")

</div>

Thanks David. I’ll take a look at that.

Mark.