Jump to content

[SOLVED] Always submit form to seperate page to validate? Or validation in same page?


Recommended Posts

Hi, new here.

 

As a general rule of thumb guys, if one exists, is it better to submit a form's variables to a new php page which does the validation and returns a user back to the orginal page if it fails, or for the page to submit the form to itself? That is, the validation code is on the same page as the form.

 

To keep things nice and neat (and mentally organised) I have been using the latter method and have been using:

if(!empty($_POST['submit_x'])) {

 

to check if the form has been submitted but I've just realised that if the user submits using <Enter> and not clicking the submit button, this variable is not present.

 

I'd appreciate some guidance if possible please.

 

I think I spend too much time worrying if I'm doing everything the "right" way sometimes when maybe I should just code something that works even if it goes against industry best practises.

 

[move]:-\  :-\[/move]

FF you can use enter and it will submit the value of submit button

im sure you are using IE..

 

now to avoid this put a hidden field and use that as replacement to your

if(!empty($_POST['submit_x'])) { 

so ti should be

if(!empty($_POST['your hidden field name here'])) {

Christ they were quick replies, is support always so fast around here?

 

FF you can use enter and it will submit the value of submit button

im sure you are using IE..

 

Yep, you got me, using IE.

 

now to avoid this put a hidden field and use that as replacement to your

if(!empty($_POST['submit_x'])) { 

so ti should be

if(!empty($_POST['your hidden field name here'])) {

 

Thanks mate, why didn't I think of that. So simple!

 

Last question, so what is the usual way of doing validation? Seperate script or in same page?

check for an input variable.

 

if(isset($_POST['var1']) && strlen($_POST['var1']>0)){
    //form was submitted and the field wasn't empty
}

else{
    //show form
}

if(isset($_POST['var1']) && strlen($_POST['var1']>0)){  <----------is almost the same

 

when i do validation i run the script on it self bu the template eg the html is on diff page

 

so itslike

 

validation here

include htmlhere

To allow previously entered values to be placed into form fields, either because they were valid or to show what was wrong with them, it is best if the validation code, processing code, and the form are all on one page.

 

However, this creates its own problem because browsers think they are doing you a favor by having nasty pop up warnings about resubmitting data when you refresh a page that is the target of a form. The solution to this problem is to actually have the form submit to a different page, have that page simply start a session, copy the POST/GET arrays to the session, then redirect back to the actual validation/processing/form page. Adding a dummy get parameter to the end of the URL in the redirect is also needed to keep the back button from navigating away from your site. Adding something like ?dummy=123 to the end of the redirect URL makes the browser think this is a different page than the original form and the back button just takes you back to the form, rather than back to the page you were on before the form page.

jibster,

 

I think you'd find people in both camps about submitting to a different page or the same one. Personally, I use both, but I prefer coding for a separate page because it's easier for me to think about. But really I'd say it's whatever works for you. I don't think there's one way that's more 'correct' than the other.

Hey PFMaBiSmAd,

 

I noticed ya said

Adding something like ?dummy=123 to the end of the redirect URL

which just brings up a question

instead of redirection, cudn the FORM ACTION add a GET paramter with a random number. so it always thinks it's a different page?

 

laffin, liked that idea. Just tested it out. Answer is sadly no.

 

Reason being that when the form is submitted to say

site.com/page.php?rand=5286

a new <form action=""> will be generated with a new random number at the end but when the site is refreshed it is the original

site.com/page.php?rand=5286

that is being re-requested, regardless of what the current random number is.

 

...

 

...

 

...

 

...I think.

Edit: Here is why that does not work -

 

I tried that using the time() function. But, because the validation/processing/form page is the direct target of the form, the pop up warning occurs when you refresh it.

 

When the the target of the form is the intermediate page that then redirects to the actual validation/processing/form page, the browser no longer thinks you are on the target of the action="...." parameter and the pop up does not occur. (If the redirect is commented out so that you stay on the intermediate page, a refresh causes the pop up.)

 

Using the dummy get parameter solves a different problem. If it is not there, then the URL of your original form and the URL of the validation/processing/form page is the same and hitting the back button takes you up one level, which could typically be the browser's default home page or a search result page (whatever page you were on before you got to the form the first time.) The back button causes you to leave the page the form in on. By having the dummy parameter, the back button actually takes you to the URL of the original form, which is actually your validation/processing/form page but without the dummy parameter on the end of the URL. You stay on the form page rather than completely leaving your site.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.