I’m curious to see how others are dealing with the construction of
multi-page forms. I can see a couple of ways to do this, each with
their own advantages/disadvantates.
Approach 1:
define one table with columns for each form entry.
define a method/view for each page, which only displays a subset of
the fields.
submitting a page saves the data and moves on to the next page.
This one strikes me as a brute force solution, but may avoid many
problems.
It may also result in tables with a huge number of columns for complex
forms.
Approach 2:
define several models and controllers that correspond to each page and
put them under another controller. (i.e., form/page1/new)
define the form model that basically just has several has_one
relationships with instances of each page
This one may be a little more logical, but it sacrifices some
flexibility. If you want to change the page layout, you may need to
move columns to a different table.
Approach 3:
define the form structure through a table, with individual field
entries being stored in another table
This is much more complex and may not be worth the effort.
Any other approaches in use? Any particular preferences in this regard?
I’m curious to see how others are dealing with the construction of
multi-page forms. I can see a couple of ways to do this, each with
their own advantages/disadvantates.
…
Any other approaches in use? Any particular preferences in this regard?
Build objects up in the session and save them when they’re ready?
I second the idea of saving the values on the db since it allows for
saving partial forms (which is nice for the user).
I’d start with analyzing where the data will be stored:
would it just be for the purpose of filling the form? Approach 1 seems
the simpler for this.
would (m)any of the fields be directly part to some other application
entity? Then I’d go for approach 2, building the objects as you go
through the intermediate steps (you might need to pose particular
attention to cleanup if such objects should not be persisted when a form
filling transaction doesn’t completes)
All in all the I think that a (moderately different) version of approach
2 sould be the most flexible: I’d start with the set of models that will
build the database handled by the form (from thw pov of the application,
e.g. person, address, …), and eventually have a model for each form
acting as an aggregation entity (maybe there’s some need for
ActiveRecord backed composition…)
Has anyone tried to impliment this? I’m curious to see what solutions
people have come up with. It seems like multi-page forms would be a
fairly common feature requirement.
-Chris