I like the idea of storing a hash of attributes. The serialization is
in your control.
Now there's nothing wrong with creating a new object and saving it
before all the data is ready. For example, you have objects that have
a parent-child relationship. You create the parent first. Then you
create the children in a loop (parent.children.create). While creating
the children, you process them to get some intrinsic value like count
(a simplistic example already provided by acts_as_tree). Then
post-loop you update the parent with the calculated value.
Of course, you could simply use the new method instead of create and
save the parent at the end, which will save the parent and children at
the same time. However if your object tree is being created
recursively, and the tree is made up of a lot of objects, and the
tables that store the objects are wide, well you can run out of memory
In any case, a solution is highly dependent on the circumstances and
problem to be solved. There's no one size fits all.
But when it comes to storing data in a session variable, the less
complex the better. As Frederick says, if you change your model and
forget to update how you store model data in the session, something
will go wrong.
Also you really should avoid storing critical data in a session. If a
cookie is lost or deleted, the application can lose track of the
session. Storing it in a database object like a Struct can be handy in
Then of course there's the old stand-by of playing hot potato, and
passing the data from one form and populating hidden fields of the next
Or you can be really hip and AJAXy and use script.aculo.us to hide and
unhide portions of a megalithic form which will make your server-side
code much simpler (1 method rather than a series of methods, 1 form
instead of many) yet to the user it'll be a wizard-like interface that
is VERY responsive. Plus it'll be easier to debug and update since it
is only one form, and you can always switch off the form_remote_tag to
regular form_tag while developing (which is recommended... get your
non-AJAX stuff working first).
So many options.