confirm b4 submit?

Before a user submits a form can I redirect them to a confirmation
page with all their fields on it, and then finally, there is a final
submit button that saves it to the database? Tanks

You could code this, yes.

You’d want to put a copy of the params hash in to the session hash and then use that hash in your final action.

Alternatively, you could use an intermediate form as your middle page that looks like a confirmation page but actually has a lot of hidden fields on it.



thanks andy,

if i went with the intermediate form option, how would i pass my
variables from the first form to the second? Thanks

if i went with the intermediate form option, how would i pass my

variables from the first form to the second? Thanks

Something like this:

class ProductController

def new

@product =


def confirm

@product =[:product])


def create

@product =[:product])




New product

<% form_for @product, :url => product_confirm_path do |f| %>

Name: <%= f.text_field :name %>

<%= f.submit %>

<% end %>


Please confirm

<% form_for @product, :url => product_confirm_path do |f| %>

Name: <%=h %><%= f.hidden_field :name %>

<%= f.submit %>

<% end %>


Product created

Something like that…



great, thanks, that helped a lot

But i was just wondering, by adding that confirm action in that
controller, does it violate the Restful Resources rules? Because I
remember Ryan Bates talking about CRUD, and that should be the only
things in the controller...

Could someone clarify on that? Thanks

It does break the principles of REST, but if you're not that worried
about being RESTful, there's no problem.

If you do want to follow rest, instead of putting the confirm action
in the ProductController, create a new controller
(ProductConfirmController, maybe) that does the functions of the
confirm in it's create method.


hmm if i make a seperate contrller, then how would i transfer my items
there to confirm the transaction?

Is it possible to transfer varialbes between contrllers or do i have
to make a seperate table? Thanks

Michael Pavling wrote:

(removed and re-posted)

An alternative strategy, assuming your app can use javascript on the
client, would be to confirm the user's action first via javascript on
the client-side before allowing the user to submit the form back to
the server.

There are many ways to do this, but the one I use most these days is
to have a (default) hidden div that contains the confirmation, such
that when the user clicks on the (pre-confirmed) action button, the
div is shown to the user and they must confirm the action to submit
the data or cancel the confirmation to keep working on the data.
Something like the following (although much better javascript alts
using one of the various js libs):

  # html/css:
  <input type="button" value="Save"
onclick="toggle_hide_show(document, 'confirm_save')" />
  <div id="confirm_save" style="display:none">
    Are you sure?
    <input type="submit" name="act_confirm_save" value="Confirm save" /

    <input type="button" value="Cancel"
onclick="toggle_hide_show(document, 'confirm_save')" />


  # javascript:
  function toggle_hide_show(doc, div_id){
    if(doc.getElementById(div_id).style.display == 'none'){
      doc.getElementById(div_id).style.display = 'block';
      doc.getElementById(div_id).style.display = 'none';


Or add a virtual attribute to the object that indicates whether
confirmation is required.

It's executing the confirmation process that seems to be troubling the
OP, not whether it's needed or not.

A second controller is unnecessary and IMHO
not particularly RESTful.

OTOH, there is nothing unRESTful about having extra controller actions
if your application needs them. The big 7 actions are not magical.

Urm... if by this you mean the names of which are given to the 7 (of
the eight possible which are normally used) are not magical, and
instead of "new" you could have "confirm", you are correct.
But how would you represent two actions which both handled a POST with
an ID while still maintaining REST? You can't have 9 controller
actions and be RESTful (unless I'm missing something about the
principles, which I'd be happy to learn). AIUI you can PUT, POST, GET,
DELETE with or without an ID, and that gives you eight methods.

If you want REST, you'll need a separate controller (or I need a
little re-education). If you're happy to forego REST, use the method
Andy suggested (it's simpler this way). Either way works fine.

then why was REST invented in the first place? or is it a convetional
thing? or is it really "better"