|multiple forms processed by same php file|
| 2:28 am on Mar 22, 2007 (gmt 0)|
We have several pages on a site that have forms in them eg page1.php, page3.php and page5.php.
they all have the same page (formprocess.php) as a action in the html form code, my scripter informed me that maintenance is easier when its all together.
To see which page has been calling the formprocess.php the scripter used something like:
It's working fine, no problems concerning that, but is this a good or bad way to work with forms?
(concerning server / page load on many people accessing different pages and not to mention safety)
Many thanks in advance for any usefull information on the subject.
[edited by: StickeR at 2:29 am (utc) on Mar. 22, 2007]
| 3:47 am on Mar 22, 2007 (gmt 0)|
|but is this a good or bad way to work with forms? |
As far as form processing there is no good/bad side to the scenario you presented. As long as the forms do the task they are supposed to do, then you win.
I have several pages with multiple forms, and the sequence of user interaction with those forms allows the page to progress to the next stage. My reasons for doing it that way was to keep everything under control in a single script. It would have been no more effort (maybe less effort) to write multiple scripts. For me, and those scripts that I wrote, maintenance is not necessarily easier at all, in fact at times a nightmare. I have to be very careful when making a simple change to ensure the page still flows as expected. But that's me.. and my scripts.
| 9:09 am on Mar 22, 2007 (gmt 0)|
I personally like to submit the forms back to themselves, so page1.php will submit to page1.php. Then at the top of the page before anything is shown i process my form, then redirect it to a thankyou.php page.
I find this easier for things like validation as everything is held on that one page. Also it means that you dont get "your page has expired" warnings when yo7u hit the back button.
| 7:47 pm on Mar 22, 2007 (gmt 0)|
It depends on how many code lays behind those forms and how much traffic you get.
Lets say programmer put processing of all 5 forms into one file. File size for example 50Kb. Each time one of the forms is posted php parser needs to load whole file, 50Kb. It will cause additional server load.
If you have separate php file for each form - less server load, because each time form is posted only required functionality will be loaded. Lets say 10Kb.
The more traffic you get - more "useless" server load you get with "all in one" approach. But if the traffic is low you would not notice the difference.
| 9:54 pm on Mar 22, 2007 (gmt 0)|
I agree JGreen -- but the decisions as to wether a single PHP is better or worse performance wise and security wise than a set of form specific ones depends on serveral things.
If the different forms have a common destination, ie a database (the same database), then the database code is probably not easily replicated over several different scripts, especially when the database code needs touching. The same also applies to code that shares many routines -- it's just not practical to have to touch more than a few copies of the same code.
The size of the script, and the time it takes to be parsed every time is also important, however, the same file, almost irrregardless of how large it is, will benefit more from the host file system's disk cache, than many smaller ones, which are more likely to fall out of the cache if they are not used frequenly. If it's a super bloated all-in-one PHP that's larger than 1 MB, it would probably benefit from some dis-integration into smaller scripts or the conditional use of includes -- I don't really like includes because they increase disk requests (and parse operations) by the script, but sometimes it's a better way.
If the forms are apples and oranges, it would probably be a better idea to keep the code independent as well.
| 10:11 pm on Mar 24, 2007 (gmt 0)|
A database is indeed being used in each script, and the file seems smaal enough (keeps growing though) at 5kb.
Thanks to all for your information.