SitePoint Sponsor

User Tag List

Results 1 to 8 of 8

Hybrid View

  1. #1
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    REST/Form actions

    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)

  2. #2
    SitePoint Enthusiast
    Join Date
    Jan 2005
    Location
    UK
    Posts
    97
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  3. #3
    SitePoint Guru
    Join Date
    Jan 2005
    Location
    heaven
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by allspiritseve View Post
    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)
    You're over thinking it.
    Creativity knows no other restraint than the
    confines of a small mind.
    - Me
    Geekly Humor
    Oh baby! Check out the design patterns on that framework!

  4. #4
    SitePoint Member
    Join Date
    Feb 2007
    Posts
    8
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I would post to the same form, save everything in session variables and redirect to the next form...

  5. #5
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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?

  6. #6
    SitePoint Zealot Amenthes's Avatar
    Join Date
    Oct 2006
    Location
    Bucharest, Romania
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.
    I'm under construction | http://igstan.ro/

  7. #7
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2008
    Posts
    5,757
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  8. #8
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by crmalibu View Post
    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?).

    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.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •