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.
[LIST]
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.
[/LIST]
Post form using a normal request and use server-side programming to return a redirect to the confirmation page.
[LIST]
Difficult to handle errors
The values of other forms will not be retained after a form submission.
[/LIST]
Post form using AJAX
[LIST]
Doesn’t work if JavaScript is disabled
Difficult to handle file uploads
[/LIST]
Post form to an invisible iframe
[LIST]
iframes are deprecated
[/LIST]
I’m interested in hearing the opinions and suggestions of others based on their experiences with form submissions.
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.
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.
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.