The database rollback on a failed save doesn’t rollback your object also. As far as it knows, it was inserted fine…
jeremy
Yup - much easier to deal with. Another option is to check .valid? on parent and children before saving.
jeremy
- But I believe the real problem is that I’m trying to build up my object in two different actions that post from 2 different pages. So I’m going to create a separate model object (not to be saved) to act as a value object to help me build my real object in the 2nd step.
Because I’m trying to build my object across multiple submits, I’m saving it to the flash and trying to keep up with its state as errors occur in various submits. And clearly, it isn’t working.
An easy approach is to use a candidate record that you save as you go. Then you can use separate validation rules for the candidate and completed models - pretty convenient - and easily ‘complete’ the candidate when the wizard’s done.
Quickly: Would Rails benefit from the use of form model objects - objects whose purpose is to keep track of the state of a form? (I think
the answer is yes).
Yes, but I think they would be mis- and over-used. Consider how far Rails has come without them.
Should we always go down the path of one form ↔ one model object no matter what (you may have many intermediate steps that you need to do in many forms in order to build your object - how is that best accomplished)?
I like the candidate record approach.
jeremy
