Multi-page forms


#1

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?

_Kevin


#2

Kevin O. wrote:

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?


David N. Welton

Linux, Open Source Consulting


#3

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…)

just my 2c.
bye
Luca M

Web: http://spazidigitali.com
Email mailto://removed_email_address@domain.invalid
Skype callto://l.mearelli


#4

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


#5

On 13 Apr 2006 16:37:18 -0000, Chris Boyce
removed_email_address@domain.invalid wrote:

Approach 1:
put them under another controller. (i.e., form/page1/new)

Any other approaches in use? Any particular preferences in this regard?

Check out acts_as_state_machine. It can help model this kind of thing.