Forum: Ruby on Rails Multi-page forms

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Kevin O. (Guest)
on 2006-02-21 03:33
(Received via mailing list)
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
David N. Welton (Guest)
on 2006-02-21 10:04
(Received via mailing list)
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
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/
Luca M. (Guest)
on 2006-02-21 11:50
(Received via mailing list)
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
--
Chris Boyce (Guest)
on 2006-04-13 20:37
(Received via mailing list)
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
Wilson B. (Guest)
on 2006-04-13 21:20
(Received via mailing list)
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.
This topic is locked and can not be replied to.