Forum Moderators: coopster
One thing I've always done, and I haven't had any problems thus far, is post forms to themselves for processing, displaying errors, etc.
I've seen more than one experienced member here make comments that they never post forms to themselves but they never seem to provide a reason. Well.... Why not?
I look at the main points like this:
Advantages
- User-friendly when displaying errors
- Centralizes form processing/management (everything is in the same file)
Disadvantages
- Possible global var confusion
- Longer parsing time/larger file sizes
I usually have someform.php and then someform.proc.php or whatever naming convention I use on any given site
- no variable corruption
- no multiple posts by refreshing the page
- if the user hits the back button on the post submit page it jumps back to the bare form
- processing has no output, just reinclude the form if you want error output
two scripts per form, ah well, html/design in one and processing in the other, works for me, though I don't always recommend this as it can complicate things too much as well
want to centralize form processing across your site, can be done
diagnostics/debugging is much simpler
I have to really keep myself in check on this topic because self submitting forms is a pet peeve of mine :)
- no multiple posts by refreshing the page
I suppose that is because someform.proc.php redirects to nextpage.php? That's exactly what I do in my single page setup.
In many cases the processing only requires three lines of code:
if (isset(somePostVar)) {
$someObject->handlePost($post);
} Waste of file system resources to create a separate file for that ;)
self submitting forms is a pet peeve of mine
Ahhh... and the reason for my post in the first place chimes in ;)
I'm in the process of completing a multi-page account set up form that jumps between 5 & 6 pages depending on user input.
I built each form to post back to itself so that I have 5/6 files instead of 10/12 files.
Even when building it I had an uneasy feeling about data corruption on refresh, back-clicks, etc. - especially since sessions are carrying the input throughout.
I guess testing will tell, but some points that jatar_k mentions make me think that complicated forms are best posted to a separate page for processing.
One trick I learned is that you can, at the end of your form processing code (this IS done before any output to the page, isn't it? ;) you can do header("Location: ["...] . $_SERVER["HTTP_HOST"] . $_SERVER["PHP_SELF"]); and the page will redirect to itself. This avoids the problem of multiple postbacks quite nicely.
Personally, I've used both methods (on-form and off-form postbacks), but I look at it from this perspective: you shouldn't be doing your form processing actually ON the page, no matter which method you use. In either case, you should have an included file containing a function (or better yet, a class) that does the processing for you.
Trying to pack both that type of logic in with the form's display logic is like attempting to ship an elephant inside a cardboard book box--everything's cramped, neither the box nor the elephant are in their proper roles, and whoever is on the receiving end of the whole mess won't be happy at all. :)
[edited by: WesleyC at 6:39 pm (utc) on Aug. 3, 2007]
you could easily post them all to a single processing script, you don't need one for each
it is much easier to make foolish mistakes with this method as well, scope problems among other things
I can concede that as an experienced programmer it may be ok, but there is no reason for beginner or intermediate programmers to use this method as the ease of use is far outweighed by the traps you set for scenarios you have yet to encounter.