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.
Cheers,
Andy
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 = Product.new
end
def confirm
@product = Product.new(params[:product])
end
def create
@product = Product.new(params[:product])
end
end
new.html.erb
New product
<% form_for @product, :url => product_confirm_path do |f| %>
Name: <%= f.text_field :name %>
<%= f.submit %>
<% end %>
confirm.html.erb
Please confirm
<% form_for @product, :url => product_confirm_path do |f| %>
Name: <%=h @product.name %><%= f.hidden_field :name %>
<%= f.submit %>
<% end %>
create.html.erb
Product created
Something like that…
Cheers,
Andy
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.
thanks,
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')" /> </div>
...
# javascript: ... function toggle_hide_show(doc, div_id){ if(doc.getElementById(div_id).style.display == 'none'){ doc.getElementById(div_id).style.display = 'block'; }else{ doc.getElementById(div_id).style.display = 'none'; } } ...
Jeff
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"