SitePoint Sponsor

User Tag List

Results 1 to 6 of 6
  1. #1
    SitePoint Enthusiast Chousho's Avatar
    Join Date
    Jun 2006
    Posts
    97
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    $_POST and refresh/going back to a page.

    I'm working on a way for users to add content to a database.
    I have a form that has an action to itself, and checks if $_POST is set.
    If it isn't, it displays the form. If it is, it adds to the database and displays a "text submitted" message.

    It works great except for a few things. If the user refreshes, it will pop up with a box saying something along the lines of, "do you want to POST again". This also happens if they go back a page, depending on the script.


    So what's a way around this? I noticed VB and other software don't have this happen.

  2. #2
    SitePoint Evangelist
    Join Date
    Jun 2003
    Location
    Melbourne, Australia
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You could have the script redirect to another request if the user-submitted data is valid. That request could display the 'success' message.
    Zealotry is contingent upon 100 posts and addiction 200?

  3. #3
    Follow Me On Twitter: @djg gold trophysilver trophybronze trophy Dan Grossman's Avatar
    Join Date
    Aug 2000
    Location
    Philadephia, PA
    Posts
    20,578
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Chousho View Post
    So what's a way around this? I noticed VB and other software don't have this happen.
    VB redirects you to a new page immediately after processing the post. If you hit refresh, you're refreshing the URL you were redirected to, which you didn't post anything to. That's the simplest solution.

    Another way to handle it is to set some flag in the user's session when they are shown the form. When you receive a form post, check that this flag is set in the session. If it is, process the post and remove the flag. If it isn't, it's a duplicate post, so you can ignore the data and display an error or redirect.

  4. #4
    SitePoint Wizard cranial-bore's Avatar
    Join Date
    Jan 2002
    Location
    Australia
    Posts
    2,634
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have functions, set_sessionMessage() and get_sessionMessage(), which allow you to give responses to form actions after a redirect (thus clearing the POST data).

    The general logic may be something like this:
    1. Show form
    2. On submit, error check, show form populated with user data on failure
    3. If valid data INSERT, set_sessionMessage, redirect back to same page
    4. If get_sessionMessage() display it
    So I use 1 script for error messages, sucess messages and to process the form.
    The script just looks for a form submission, or a previously stored sessionMessage to display. After successful submission the user can refresh or go back without reposting the form.

    get_sessionMessage also REMOVES the message from the session after returning it, so that it isn't displayed the next time the page is loaded (unless another form submission is made).

    It's also a good idea to draft off all your long winded form validation, processing and presentation logic to separate classes/functions so you don't end up with a monster procedural script with 1000 lines of code. Very hard to maintain and understand. Also avoids having huge if, else() blocks.

  5. #5
    SitePoint Enthusiast Chousho's Avatar
    Join Date
    Jun 2006
    Posts
    97
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for the ideas, all! Just some notes
    Quote Originally Posted by Dan Grossman View Post
    Another way to handle it is to set some flag in the user's session when they are shown the form. When you receive a form post, check that this flag is set in the session. If it is, process the post and remove the flag. If it isn't, it's a duplicate post, so you can ignore the data and display an error or redirect.
    This would be ok for inserting data into the db, but I was also hoping for a cleaner user experience as well. While it would work, would you still get that ugly popup about POST data?
    Quote Originally Posted by cranial-bore View Post
    I have functions, set_sessionMessage() and get_sessionMessage(), which allow you to give responses to form actions after a redirect (thus clearing the POST data).

    The general logic may be something like this:
    1. Show form
    2. On submit, error check, show form populated with user data on failure
    3. If valid data INSERT, set_sessionMessage, redirect back to same page
    4. If get_sessionMessage() display it
    So I use 1 script for error messages, sucess messages and to process the form.
    The script just looks for a form submission, or a previously stored sessionMessage to display. After successful submission the user can refresh or go back without reposting the form.

    get_sessionMessage also REMOVES the message from the session after returning it, so that it isn't displayed the next time the page is loaded (unless another form submission is made).

    It's also a good idea to draft off all your long winded form validation, processing and presentation logic to separate classes/functions so you don't end up with a monster procedural script with 1000 lines of code. Very hard to maintain and understand. Also avoids having huge if, else() blocks.
    Hmm, this is interesting. As I'm moving into doing this all in OOP from what was previously procedural I'm a bit curious. As of now I have a class that handles manipulation and creation of the data. In this class I have a method that displays the form and is basically a self contained page, and I know it's a horrible way to do it, but I'm also not too familiar with templating (and I'm a bit hesitant about using an outside template engine until I understand how it work better, in which I would rather just write my own eventually, anyway).

  6. #6
    SitePoint Evangelist
    Join Date
    Aug 2005
    Posts
    453
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Chousho View Post
    I'm working on a way for users to add content to a database.
    I have a form that has an action to itself, and checks if $_POST is set.
    If it isn't, it displays the form. If it is, it adds to the database and displays a "text submitted" message.

    It works great except for a few things. If the user refreshes, it will pop up with a box saying something along the lines of, "do you want to POST again". This also happens if they go back a page, depending on the script.


    So what's a way around this? I noticed VB and other software don't have this happen.
    The way around this is to use a form handler page. Instead of trying to send the post data to the same form, send it to a form handler. The handler page does the grunt work and writes messages (either success or failure and failure cause to a session variable). The the handler script then uses header() to send you back to the referring page. You break your code up into more manageable chunks and you separate your database code from the form code.
    The message you get on refresh states that the request contains post data and would you like to resubmit the data. With a form handler this never occurs because the post data is sent to a form handler and the form handler sends you back full circle minus post data.
    Computers and Fire ...
    In the hands of the inexperienced or uneducated,
    the results can be disastrous.
    While the professional can tame, master even conquer.


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
  •