I currently am working on a shopping cart. The checkout process is a sequence of forms, in which one form POSTs to the next form in order to move the customer to checkout. However, I'm starting to rethink the decision to POST to the next form, and am thinking maybe it's better to have each form POST to itself, and then redirect. Here are my thoughts:
Pros of posting to the next form:
- Single point of entry for adding things to cart, for example. Reduces code duplication.
- Treats each form as a REST-like resource (collection?) that can be added to.
Pros of posting to same form:
- All content on the page can be saved. For example, if a user modifies a quantity in the cart and hits checkout instead of update cart, that number will still be saved.
- More control over the flow-- if a user needs to be directed to a different checkout page based on their membership level or whatever-- that can be done.
Which is better? To POST to the next form in the sequence, or POST to the same form and redirect? Or should some forms work one way, and some another? Am I overthinking this? (probably)
I've always POST to same form and then redirected when I've built shops, gives you much more control over what happens, for a simple cart it might not matter but as soon as you start adding VAT, different delivery address, shipping calculations, vouchers, gift warpping and anything else you will prefer dealing with each step on its own.
You're over thinking it.
Originally Posted by allspiritseve
I would post to the same form, save everything in session variables and redirect to the next form...
I guess it's settled then, POST to self and redirect.
Out of curiousity, can anyone think of any scenarios in which POSTing to a separate script would be useful?
I wouldn't call it a separate script, but wizard forms may require an extra query
param in the URL, like index.php?step=2.
If you had a multipage form, and you wanted the allow the user to open a new window and branch at any time(maybe, like a long practice quiz), then a post without a redirect offers easy support for this because you can embed any accumulated data directly into hidden fields. Multiple browser windows or tabs don't cause problems.
If you did post > redirect, I think you would need to do something like post > use data to create unique url for current accumulation of data > redirect to thier url. Typical cookie based sessions alone wouldn't handle it well.
Thinking about it, I guess I'm talking more about a session state issue that happens to be common to post > redirect.
Yes, this is why redirect-after-post should be more accurately named redirect-after-successful-post-but-redisplay-upon-failure. For a multipage form, your suggested solution would be proper rest, but could cause some problems in usability (How do you open a new tab as a POST action?).
Originally Posted by crmalibu
I think that in most cases, a multipage form probably needs serverside state to work as expected. You don't have to make it singleton for the session though; You could create a new resource in the beginning of the process, and continue from there. For example, let's say you have a five-step checkout process, the first step might be at /checkout/ but when you submit that, you get redirected to /checkout/3e1d583c/2 (As opposed to just /checkout/2) and the following steps follows this scope, eg. step #3 at /checkout/3e1d583c/3 etc. The id being a random key, that might be stored in session or database. The point is that the user could open several simultaneous flows.
You could even extend this to branch the state at each step - cloning the state under a new key. Eg. from /checkout/ you might go to /checkout/3e1d583c/2, and then to /checkout/090bd6e9/3. If you then go back to /checkout/3e1d583c/2 ad re-submit the form, you'd go to /checkout/d9c944af/3 (As opposed to /checkout/090bd6e9/3). Rather than changing the state of a URL, you create new ones. This means that while the data is stored on the server side, the application state is controlled by the client. A technical problem of it is that this takes up some space on the server side, but that can be dealt with. This concept is known as continuations and if you must have server side state, I think it's a pretty neat idea.