Forum: Ruby on Rails newbie question

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.
Thila T. (Guest)
on 2006-06-03 18:49
All experts out there,
I went thru the archives and aparantly lot more people have the same
problem as me. I would like someone to answer the following question.

Question: How to handle multiple rows in a single form?

Example: Say there is a employee class, with the following 4 attributes
   1. name  (text field)
   2. sex (radio button)
   3. state (drop-down)
   4. company policy indicator (check box)

I would like to have a form with multiple rows of the employee class.
Can someone please walk-thru what should happen on the controller and as
well the html. Most of us are comfortable in reading and writing to the
database tables, but confused on the form presentation and handling the
request data on the controller side.

Thanks for you help.
David J. (Guest)
on 2006-06-04 01:12
(Received via mailing list)
... listening ...
Nate C. (Guest)
on 2006-06-04 01:22
the easiest way to understand how forms work is to start with
scaffolding... have you created scaffolding for your employee class and
controller?
David J. (Guest)
on 2006-06-04 01:43
(Received via mailing list)
The edit form generated by the scaffolding presumes one-screen = one-
row.  Composite input forms such as desktop app designers are used to
are not expressed in the scaffolding.

The issue is how to best take that scaffolding code and extend it to
support editing a set of rows (employees in thilla's case, quiz
responses in my case) so one-screen = arbitrary-n-rows.

There is enough there that an experienced HTML programmer could probably
figure out how to adapt the code.  But those of us coming from Delphi,
Swing, Qt, kde, or other desktop GUI environments walk into a gaping
hole in the published documentation.

I can see the outline of the shape of the solution, but I'm missing the
meat of the pattern (to mix metaphors really badly).  This part of the
learning curve is either presumed to be something that is already common
knowledge, or is not the "rails way to do things".

If I'm not mistaken, the trick will be to name the input elements in the
cells of the HTML table in such a manner that Rails will populate the
@params hash from the data submitted.  Can we get more specific than
this generic statement?
David J. (Guest)
on 2006-06-04 06:50
(Received via mailing list)
I think that the answer you are looking for has been answered on another
thread that I started yesterday.  Check out David F.'s response to
                           Subject:
Re: [Rails] How to get dynamically
created inputs from html form back
to rails app
                              Date:
Sat, 3 Jun 2006 14:49:55 +1000
(Fri, 23:49 CDT)

I think that his response should give you sufficient information to get
you started.

If I understand his example correctly, name your elements name[], sex[],
state[], and policy[].  They will then be returned to the rails app as
ordered hashes of their respective data.  Your save method in the
controller will traverse the hashes and apply the information to the
properties of the child ActiveRecord.
This topic is locked and can not be replied to.