Same form processing?

[anthonyjpv]

If php file cannot be viewed from users browser,

what are the advantages and disadvantages of having to process a form in same php file

or processing a form with a different script?

ie

mail_form.php

or with process_mail.php

thanks!

[pritaeas]

If you process a form in the same file, you have to account for the fact that a user can press refresh, resending the form. That is less likely with a separate processing script. But of course, that can all be handles. I do not think one is much better than the other.

[weekendrockstar]

The only real difference is that after when using the same page to create the form and handle the submission is that you can post error or success messages above the form and they will be able make any additional changes from the same page. Or if an error is generated (such as one of the input data doesn't match proper criteria which you set in PHP code) the form is already available for them to try again.

If you use a separate PHP page to process the form you would either have to add a link to go back to the form page in the event of an error (after you've hopefully informed them of what the error is...like if they left a field blank which you tell the script cannot be left blank with PHP code) or make it print out the form again on the processing page. But if you print the form on the processing page it would just send to itself to process the data which then turns it into one page creating the form and processing the data anyway.

When possible I try to handle showing the form, processing data and showing success or error messages all with one PHP file.

As pritaeas mentioned you should run a check on the submitted data if it is saving to a database where the row has a UNIQUE key and you do not want more than one row per person in the database. For example: if this were for a script where visitors can leave you a message regarding your site and you have another script which shows the data submitted as a page that you can view...you don't want multiple "messages" that are the same from the same person. If they accidentally refresh the page after a submission it would naturally create another row with all of the same information. But in my example you can take the data such as a name they supplied in a text field, their e-mail address they supplied for you to get back to them and the message content and upon submission it can check that there isn't already a row in the database that matches all three pieces of data.

It should be okay if the name and e-mail address they supply are the same because they could contact you using the form several times. And although it would be nearly impossible for someone to send you EXACTLY the same message word-for-word you would want to allow it if the name and e-mail address they supplied are different otherwise it wouldn't save the second person's contact submissions to the database because the message content is in the database. Again, it would be EXTREMELY rare that it would happen but it's generally best to code for anything that is POSSIBLY to occur no matter how unlikely it may be.

If your code matches a name, e-mail address and same exact message is already in the database you can make it not save to the database and display an error that they've already performed the function (in the example they've already sent that contact message to you). This should avoid multiple database table rows that are the same. As pointed out this could be more likely if you use the same PHP page to show the form and handle the content but this check should also be applied even if the processing is done on a second page because again, it is possible that it can happen so you should plan for it.

Of course my example was quite case-specific but you can apply the same logic to data checking to suit the needs of the form data you are submitting and how the database stores it.

[Biiim]

In an external file you can make quite generic then you can attach it to multiple forms such as a process script that expects post data, an email address, from line and redirection page and just checks and emails it using the data.

You can then link 10 forms to it and any updates update all 10 cutting out alot of the work, it's nice to build up a collection of these types of modules you've written makes writing much much quicker when you can bolt your already written code together to make something

[weekendrockstar]

In an external file you can make quite generic then you can attach it to multiple forms such as a process script that expects post data, an email address, from line and redirection page and just checks and emails it using the data.

You can then link 10 forms to it and any updates update all 10 cutting out alot of the work, it's nice to build up a collection of these types of modules you've written makes writing much much quicker when you can bolt your already written code together to make something

That is quite true. External module files entered my mind but I thought that it was outside the scope of the original question about using one or multiple pages for forms and data processing. But this is true of anything that you code which may be used multiple times within one project or all that you ever code. It will cut down programming time and save on server bloat having it stored in an included external file rather than re-using the same code every thing that you want the same process done. Especially if you're coding a large project with MANY different pages. Such as if you have a login system which is used with every page load there's no reason to have the function coded in every PHP file. Just call the function from the included module file and you reduce each file's size dramatically by using only one line of code.

[diafol]

Personally, I favour separation. The refresh/reload problem is sufficient reason for me. Placing data back into the form following a failure (e.g. showing username/email data in login form if p/w is wrong). You'll be using sessions anyway, so simply place $_POST data and any error messages into $_SESSION and then redirect back to the form page.
Check to see if $_SESSION exists, if so, extract to $form or similar and unset $_SESSION. Then populate placeholders in the form.
There are other ways of course.

[anthonyjpv]

THANKS! for ALL your help! I really appreciate your help pro's! Im marking this as solved! Very satisfied with your answers! once again THANKS!