How Does RoR Handle...

[skeeterbug]

a website that has multiple form inputs?

let me illustrate.

agile webdev outlines an admin page and a store page. the admin page enters one thing - products. there is an admin controller and there is a products model and there is an admin view. makes sense.

i have an app up and running in php. i have a similar admin page, except i call it maintenance. instead of updating a single item, i have a menu of items to update. let's say - customer, product, employee.

in php, i just have 3 logic pages (eg, customer.php) and 3 templates (maintenance/customer.tpl.php). of course, i have a side menu that links to these pages. this is easy to wrap one's mind around.

how does RoR handle this kind of scenario? i doubt more than one controller would be used - otherwise my php app would have the motherload of controllers because the maintenance functionality doesn't touch the surface of the apps capability.

i'd like to port the app over to RoR so i can better learn RoR. i'm up to the shopping cart portion of RoR, but i haven't been able to grasp how this might be done. my guess is that multiple views have to be mapped to a "maintenance" controller and there would be different methods to do the different db deeds.

can anyone elaborate how this should be done?

[vgarcia]

You can put multiple forms in the same view, then just have their actions point to different controllers. For example, if you had a form to add users and add products on the same page, the user form would submit to a URL like /users/new and the product form would submit to /products/new. From there, you can then redirect back to your "master" page.

[skeeterbug]

You can put multiple forms in the same view, then just have their actions point to different controllers. For example, if you had a form to add users and add products on the same page, the user form would submit to a URL like /users/new and the product form would submit to /products/new. From there, you can then redirect back to your "master" page.

based on this, it seems like you are suggesting having all the form elements on one page, each with its own submit button. based on the button pressed, it would submit to the correct method. i wasn't too clear, but this won't work. i oversimplified the reality - some forms have multiple elements and i actually have a few more pages than 3. more like 6.

here's what i'm thinking.

1 controller for app maintenance functions (there will be controllers for other functions, too).
2. i would create a method for each display page and use the layout, inject form form element code method to display the forms.
3. i somehow need to work with the model to get it to do the db work once the form is submitted. i have to review some code to see how this is done.

does this seem reasonable? is it consistent with the RoR way?

can anyone toss out some hints how to handle the model(s) portion of this way of doing things?

tia...

[skeeterbug]

You can put multiple forms in the same view, then just have their actions point to different controllers. For example, if you had a form to add users and add products on the same page, the user form would submit to a URL like /users/new and the product form would submit to /products/new. From there, you can then redirect back to your "master" page.

based on this, it seems like you are suggesting having all the form elements on one page, each with its own submit button. based on the button pressed, it would submit to the correct method. i wasn't too clear, but this won't work. i oversimplified the reality - some forms have multiple elements and i actually have a few more pages than 3. more like 6.

here's what i'm thinking.

1 controller for app maintenance functions (there will be controllers for other functions, too).
2. i would create a method for each display page and use the layout, inject form form element code method to display the forms.
3. i somehow need to work with the model to get it to do the db work once the form is submitted. i have to review some code to see how this is done.

does this seem reasonable? is it consistent with the RoR way?

can anyone toss out some hints how to handle the model(s) portion of this way of doing things?

tia...

after thinking about thi sfor a bit, i think each form gets its own model b/c each form entry goes to a separate db table. i think the model maps, conceptually, to the view since a view that updates 2 linked tables would have only one model to do the updating.

i'm not sure if this makes sense, but it is where my head is right now.

[alistair_b]

I actually have a similar problem at the moment. Except I may have to do 1 form that covers 2 tables (ActiveRecords if you like) that have a 1->* relationship

Now isn't that funky