SitePoint Sponsor

User Tag List

Results 1 to 5 of 5
  1. #1
    @alexstanford Alex's Avatar
    Join Date
    Apr 2004
    Location
    Jacksonville, Florida
    Posts
    757
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    Handling Form Submissions (the best way(s)...?)

    Lately I've been ruminating over how form submissions should be handled on the web. The only conclusion I've formed is that I can't come to a conclusion at all. I'd like to hear other's views on the subject and hopefully even learn of more possibilities.

    Here are the options I've come across along with the drawbacks that I've recognized with each...


    • Post form using a normal request and use server-side programming to return the form with errors or return a confirmation page.
      • If you navigate back in your browser after successfully submitting the form you will resubmit the form.
      • The values of other forms will not be retained after a form submission.

    • Post form using a normal request and use server-side programming to return a redirect to the confirmation page.
      • Difficult to handle errors
      • The values of other forms will not be retained after a form submission.

    • Post form using AJAX
      • Doesn't work if JavaScript is disabled
      • Difficult to handle file uploads

    • Post form to an invisible iframe
      • iframes are deprecated



    I'm interested in hearing the opinions and suggestions of others based on their experiences with form submissions.
    Alex Stanford @alexstanford tumblog about.me in fb G+ K
    TechTalkin The Premier Community for Technology Enthusiasts and Professionals
    Full Ambit Media Zero Sacrifice Web Design & Development; Made in the USA @fullambit in fb G+ K

  2. #2
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,323
    Mentioned
    462 Post(s)
    Tagged
    8 Thread(s)
    What's your ideal scenario? A common one is for the same page to be returned if there are errors, with the errors shows and the form still visible, with the entered data still showing. You could do the same for the confirmation page, too, if you wanted.

  3. #3
    @alexstanford Alex's Avatar
    Join Date
    Apr 2004
    Location
    Jacksonville, Florida
    Posts
    757
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ralph.m View Post
    What's your ideal scenario? A common one is for the same page to be returned if there are errors, with the errors shows and the form still visible, with the entered data still showing. You could do the same for the confirmation page, too, if you wanted.
    Hi Ralph,

    I'm speaking in more of a general use sense rather than my idea scenario. Consider a contact form, shopping cart checkout, survey or any other common online form as examples.

    Indeed you're correct that it is very common to return the same page with errors injected and fields highlighted or just a confirmation page. (this is how I currently do things in fact) This relates to the first method I proposed. I'm not sure this is the best method though. As noted, the issues I've found are as follows:

    • If you navigate back in your browser after successfully submitting the form you will resubmit the form.
    • The values of other forms will not be retained after a form submission.

    This is even how the Ruby on Rails framework handles forms. Though last I checked, Rails returns the errors at the top of the form with the fields highlighted. I actually return the errors under the fields they pertain to along with highlighting. But, this is still only a trivial UI improvement that doesn't address the above mentioned issues.
    Alex Stanford @alexstanford tumblog about.me in fb G+ K
    TechTalkin The Premier Community for Technology Enthusiasts and Professionals
    Full Ambit Media Zero Sacrifice Web Design & Development; Made in the USA @fullambit in fb G+ K

  4. #4
    Programming Team silver trophybronze trophy
    Mittineague's Avatar
    Join Date
    Jul 2005
    Location
    West Springfield, Massachusetts
    Posts
    17,262
    Mentioned
    196 Post(s)
    Tagged
    2 Thread(s)
    Just because someone can "back" to the form and send the submit doesn't mean the server must use it, no? An
    "already in database" type of message could be returned, preferably with an option to edit.

  5. #5
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Mittineague View Post
    Just because someone can "back" to the form and send the submit doesn't mean the server must use it, no? An
    "already in database" type of message could be returned, preferably with an option to edit.
    Or a 'not in database' for that matter -- in general you should never 'blindly accept' a form without some form of verification hash -- and those other 'methods' do nothing to prevent resubmits.

    Make a random value, store it in a database with a expiration time and maybe the users IP addy, when they submit delete all expired times, then check if it's still in there. If it is, delete it and it's a valid submit, if it's not there -- they hit back or a spambot is trying to mass-hit you.

    Simple. those other methods you mention don't actually do anything to prevent resubmits; since back would/could/should reload everything.

    It's also why if you'll recall (since if I'm not mistaken you're still working off a baseline code I wrote), I use the same php file and URL to show the form as I do to submit the form -- with a hidden input to say it's submitted 'from form' -- interestingly hitting back should not resend any data, rejecting for empty fields and/or that value not being set -- if the browser does resubmit, that's when you use the database hash to reject it.


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
  •