Forum Moderators: coopster

Message Too Old, No Replies

Posting Forms to Themselves or Different Page

Which method do your use/prefer and why?

         

justgowithit

4:10 pm on Aug 3, 2007 (gmt 0)

10+ Year Member



The more I learn about programming the more habits I find to correct.... err.... improve.

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

RonPK

4:35 pm on Aug 3, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



I usually have forms posted to themselves. If the post is valid: perform action (like entering stuff into database), and redirect to the next page. If not, show the form again with an error message.

That keeps the form and the processing code conveniently in one file (unless OOP).

d40sithui

5:16 pm on Aug 3, 2007 (gmt 0)

10+ Year Member



yea i totally agree. i always post forms to the same page. makes things a lot easier. everyone should do it!

jatar_k

5:23 pm on Aug 3, 2007 (gmt 0)

WebmasterWorld Administrator 10+ Year Member



or even no one should do it

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 :)

RonPK

5:51 pm on Aug 3, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



- 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 ;)

justgowithit

6:24 pm on Aug 3, 2007 (gmt 0)

10+ Year Member



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.

WesleyC

6:38 pm on Aug 3, 2007 (gmt 0)

10+ Year Member



I guess you guys had better never, EVER look at ASP.NET then, as literally almost every control is designed to do postbacks to the same page. :) It can be quite the hassle sometimes.

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]

jatar_k

9:09 pm on Aug 3, 2007 (gmt 0)

WebmasterWorld Administrator 10+ Year Member



>> so that I have 5/6 files instead of 10/12 files.

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.