NYCPHP Meetup

[Cliff Hirsch]

On 6/11/07 11:57 AM, "Chris Shiflett" <shiflett at php.net> wrote:

> Cliff Hirsch wrote:
>> Header redirects seem to solve the back/resubmit problem, but create
>> duplicate processing on the server side and generally add session
>> overhead. For a successful form submission, the ³thanks redirect²
>> probably need to grab data again. For a bad form submission, the
>> postdata probably needs to be stored in a session to be echo¹d back.
> 
> I might be wrong, but these comments make me think you misinterpreted
> the article.
> 
> 1. Why is there any duplicate processing?
A Form submission would start by running the front-end controller, which
loads a whole lot of classes, checks authentication, establishes the DB
connection, inits sessions, sets up the template controller, and other
housekeeping chores.

The way I understand it, we would do all that, and then when the script
finally gets to the action related to the form submission, we would
redirect, which would go through that initial process all over again --
essentially scrapping that first pass of cycles. Am I missing something
here?

> 2. What is the basis of your concern regarding session overhead? You can
> persist data in cookies, if it's really a concern.
This probably dates back to a presentation at the Zend conference several
years ago given by Joyce from Renkoo regarding the evils of sessions. But I
use them, so what's another few fields. I've all but given up on minimizing
SQL hits. More session variables do mean more states to run amok though.

> 3. What is a thanks redirect, and why must it grab data again?
By this I meant the page following a form submission. Say the form did
something as simple as store a record in a DB. Now if we redirect, and want
to say, "hey thanks for submitting this data", we need to query the DB to
retrieve it. Without the redirect, we would innately have the data, since
we're still in the same script that processed the form.
 
> 4. If a form submission is deemed bad, you can opt to display the form
> again with the errors noted, but the 302 redirect is the only way to
> prevent the back / forward warning.
Seems like I just have to model human behavior versus performance and do
what is most intuitive for the end-user.