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
On 14 April 2010 02:57, David Z. [email protected] wrote:
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
On 14 April 2010 23:23, David Z. [email protected] wrote:
But i was just wondering, by adding that confirm action in that
controller, does it violate the Restful Resources rules?
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
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 B. talking about CRUD, and that should be the only
things in the controller…
Could someone clarify on that? Thanks
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):
in html/css:
…
Are you sure?
...
in 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
Michael P. wrote:
On 14 April 2010 23:23, David Z. [email protected] wrote:
But i was just wondering, by adding that confirm action in that
controller, does it violate the Restful Resources rules?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.
Or add a virtual attribute to the object that indicates whether
confirmation is required. 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.
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
(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:
…
Are you sure?
…
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
On 15 April 2010 06:38, Marnen Laibow-Koser [email protected]
wrote:
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”