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 -- Posted with http://DevLists.com. Sign up and save your time!
Kevin Olbrich 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/
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://l.mearelli@spazidigitali.com Skype callto://l.mearelli --
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 On Tuesday, February 21, 2006, at 1:32 AM, Kevin Olbrich 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. > >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 > >-- >Posted with http://DevLists.com. Sign up and save your time! >_______________________________________________ >Rails mailing list >Rails@lists.rubyonrails.org >http://lists.rubyonrails.org/mailman/listinfo/rails-- Posted with http://DevLists.com. Sign up and save your mailbox.
On 13 Apr 2006 16:37:18 -0000, Chris Boyce <devlists-rubyonrails@devlists.com> wrote:> 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 > > On Tuesday, February 21, 2006, at 1:32 AM, Kevin Olbrich 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. > > > >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? > >Check out acts_as_state_machine. It can help model this kind of thing.