NYCPHP Meetup

NYPHP.org

[nycphp-talk] Form PRG revisited -- again

Cliff Hirsch cliff at pinestream.com
Tue Jun 12 16:25:19 EDT 2007


I have been testing the Form PRG pattern, and really like the way it acts on
the user side. The back button and resubmit/reload button behave so much
nicer, versus those ugly POSTDATA messages. But it is a bear to implement,
unless I¹m missing something as usual.

Paul Jones showed how the Solar Framwork supports redirectNoCache function.
But this is just a small part of the equation. For a redirect after a
successful form submission, its a no-brainer ‹ clean and simple. The problem
is forms with errors. These forms need to be presented to the user again,
with all relevant data and error messages ‹ inline and otherwise.

To me, this means the following:
1. Process the form via post for the first pass
2. Redirect to display form again via get with data and error msgs. This
means not just presenting the form again, but also the previously form data,
and all error messages, which means processing/validating the form to catch
the error messages, but not redirecting this time round.

This is a major pain.  Every form controller/action needs to be tweaked.

Am I reinventing the wheel here? Time to switch to ASP or Java?!

I see several options:
1. Skip the PRG pattern. Let users struggle with the back/resubmit buttons.
2. Go for the low-hanging fruit ‹ redirect only after successful form
submissions 
3. Use AJAX to ³pre-validate² a form prior to submission
4. Make a global PRG function at the start of the controller like so....

if form post submission
   save post variables in session
   redirect to same URL (add post/timestamp tag or some other identifier if
necessary?)
elseif (isset(post/timetamp/identifier tag) && that tag  passes some
validation step)
    get saved post variable from session and repopulate $_POST array
    clear post variables from session
    continue on our merry way as if this were a post submission
         (but how do our controller/actions detect get versus post
submissions ‹ looking for a post variable or some http field?)
else
    clear post variables from session, if any

What do you think? Seems to make sense. This essentially turns every post
into a get. To the forms, it should be transparent ‹ right? We could still
redirect for results pages when desired on a case-by-case basis so that the
reload button displays the results again instead of the original form. And
we do this as close to the top the script as possible, right after session
initiation, to reduce unnecessary server load.

Cliff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20070612/1c79fa24/attachment.html>


More information about the talk mailing list