Hello, Is there an elegant way to handle forms in a controller/view that need to go thru multiple steps. Like 1) validating content, and 2) adding a step like first accepting an Agreement? Just wondering if rails had a way to handle this without me having to post to the controller twice and render a view based on a hidden form value (input type=hidden name=step value=2 kind of thing) thanks adam
sorry for re-posting this, my first one didnt seem to get through. Is there an elegant way to handle forms in a controller/view that need to go thru multiple steps. Like 1) validating content, and 2) adding a step like first accepting an Agreement? Just wondering if rails had a way to handle this without me having to post to the controller twice and render a view based on a hidden form value (input type=hidden name=step value=2 kind of thing) thanks adam
On Friday 18 November 2005 01:08, Adam Denenberg wrote:> sorry for re-posting this, my first one didnt seem to get through. > > Is there an elegant way to handle forms in a controller/view that > need to go thru multiple steps. Like 1) validating content, and 2) > adding a step like first accepting an Agreement? > > Just wondering if rails had a way to handle this without me having > to post to the controller twice and render a view based on a hidden > form value (input type=hidden name=step value=2 kind of thing)No, AFAIK Rails doesn''t handle it for you. You need to develop your own solution for the problem. My guess would be to create an inermediate object, something like ModelConstructor that will encapsulate models you''re creating from the forms and handle their validations. Then you can store this object in session, without saving it to the DB until the final step is over. You can handle validation in middle steps by calling Rails validate method inside Constructor object and by stripping off all not-yet-filled fields from errors hash, to check if model is correct for the current step. Hope that helps.> thanks > adam > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-- Dmitry V. Sabanin http://sabanin.ru
Adam Denenberg <straightflush@...> writes:> Is there an elegant way to handle forms in a controller/view that > need to go thru multiple steps. Like 1) validating content, and 2) > adding a step like first accepting an Agreement? > > Just wondering if rails had a way to handle this without me having > to post to the controller twice and render a view based on a hidden > form value (input type=hidden name=step value=2 kind of thing)I''m not sure if these are what you''re looking for, but here are three tricks I''ve used: 1. As long as you put your validation in your models, you get all the cool validation effects (like feedback on the form telling people what they did wrong, bad fields being highlighted, etc.) for free--no need to do separate pages for validation. This knocks out a lot of the things you would need hidden fields for one one fell swoop. 2. The Rails generators create CRUD scaffolding that uses two actions for some transactions that you could really do in with a single action (example: "new" to display a blank form to collect data, and "create" to accept that data and actually save it into the database). You can easily combine related operations like this into a single controller by triggering one operation if the action is called with HTTP GET, and the other if it''s called with HTTP POST. You write the action code something like this: def new if request.get? # Code to display blank form, or whatever else # Comes here for POST--put code to save form data here end end This trick basically just buys you the appearance of being on the same web page (because the URL doesn''t change), when in fact you''re executing and rendering completely different code. 3. Create a second form for subsidiary data (perhaps like asking for acceptance of an agreement, as you were asking about) and put it inside an HTML "div" element with inline style set to "display:none;" so that it''s invisible, and overrides it''s main CSS styling. Use Javascript to take the main form''s "submit" button, and instead of submitting, wire it to use one of the cool Script.aculo.us effects in Rails to make your secondary form visible on top of the main form. You use Javascript on this secondary form''s "submit" button to make it submit the original form when clicked. #1 and #2 are pretty straightforward and standard. #3 takes a little more work, and can be very impressive; lots of variations on that approach are possible. To see one example, take a look at the search box on the main Script.aculo.us page (http://script.aculo.us), and click on it''s "advanced options" link. --Forrest
thanks forrest. Step 3 actually sounds like a really interesting way to avoid multiple posts thru a 3 step form. i assume the initial form''s submit button is actually not a submit button , but just a "button" with an onClick handler that turns the License Agreement div from display:none to display:block which also producces a submit button. I will try this out howevr i have run into issues where combining ajax and forms starts preventing certain data from being submitted but i will definitely give this a shot. thanks for the ideas. adam On 11/17/05, Forrest Thiessen <thiessen-I0D8NflN0vzU+KD/reu1CkEOCMrvLtNR@public.gmane.org> wrote:> Adam Denenberg <straightflush@...> writes: > > Is there an elegant way to handle forms in a controller/view that > > need to go thru multiple steps. Like 1) validating content, and 2) > > adding a step like first accepting an Agreement? > > > > Just wondering if rails had a way to handle this without me having > > to post to the controller twice and render a view based on a hidden > > form value (input type=hidden name=step value=2 kind of thing) > > I''m not sure if these are what you''re looking for, but here are three tricks > I''ve used: > > 1. As long as you put your validation in your models, you get all the cool > validation effects (like feedback on the form telling people what they did > wrong, bad fields being highlighted, etc.) for free--no need to do separate > pages for validation. This knocks out a lot of the things you would need hidden > fields for one one fell swoop. > > 2. The Rails generators create CRUD scaffolding that uses two actions for some > transactions that you could really do in with a single action (example: "new" to > display a blank form to collect data, and "create" to accept that data and > actually save it into the database). You can easily combine related operations > like this into a single controller by triggering one operation if the action is > called with HTTP GET, and the other if it''s called with HTTP POST. You write the > action code something like this: > def new > if request.get? > # Code to display blank form, or whatever > else > # Comes here for POST--put code to save form data here > end > end > This trick basically just buys you the appearance of being on the same web page > (because the URL doesn''t change), when in fact you''re executing and rendering > completely different code. > > 3. Create a second form for subsidiary data (perhaps like asking for acceptance > of an agreement, as you were asking about) and put it inside an HTML "div" > element with inline style set to "display:none;" so that it''s invisible, and > overrides it''s main CSS styling. Use Javascript to take the main form''s "submit" > button, and instead of submitting, wire it to use one of the cool > Script.aculo.us effects in Rails to make your secondary form visible on top of > the main form. You use Javascript on this secondary form''s "submit" button to > make it submit the original form when clicked. > > #1 and #2 are pretty straightforward and standard. #3 takes a little more work, > and can be very impressive; lots of variations on that approach are possible. To > see one example, take a look at the search box on the main Script.aculo.us page > (http://script.aculo.us), and click on it''s "advanced options" link. > > --Forrest > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >