On Tue, 2006-05-23 at 15:01, Paul Novitski wrote:
> An additional strategy to make your system more robust is to use
> three pages for your form submission:
>
> 1) the form itself, which submits to:
> 2) the script that processes input, which redirects to:
> 3) the page that displays the results (or is the next form in a sequence).
>
> Even if the user reloads the results page (3) they won't be
> resubmitting the form (1) or repeating the input processing (2).
At 01:02 PM 5/23/2006, Robert Cummings wrote:
I think a 2 page scenario is simpler and more elegant:
1) the form itself, which submits to itself for validation
and re-presenation in case of validation errors
(including multiple submission of same form - such as
going back in browser). This also means if errors occur
then the form can be presented with previously
submitted data.
2) the final destination page(s) after the form has been
submitted with successful validation to which the user
is redirected (preventing reload submissions).
Robert, you're absolutely right: there's no reason why my pages 1) &
2) can't be the same script posting to itself, and in fact the
two-page model you describe is what I most often use in
practice. Perhaps I should have written "step" instead of "page"...
To take your point further, the process would be even simpler & more
elegant if we stuck with a single script-page that displayed the
form, processed input, and displayed the results. If the server-side
script is doing its homework, even separating out the results page
isn't necessary since the form-processor has to be on guard against
multiple executions regardless of the cause. Reloading the script
when it's in "results" mode isn't a big deal because it's smart
enough not to process the same input twice.
There are occasionally some practical reasons for making the
separation. A few years back I wrote an action center engine that
drove letter-writing campaigns run from many different environmental
websites. We let each client site host the introduction and the
final thanks page, but the intervening 'action engine' that processed
input and generated email & faxes was resident on our domain. I'm
sure many users were never aware that they'd left the client site for
the duration of the processing.
Regards,
Paul
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
