On 6/11/07 11:57 AM, "Chris Shiflett" <[EMAIL PROTECTED]> 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. _______________________________________________ New York PHP Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk NYPHPCon 2006 Presentations Online http://www.nyphpcon.com Show Your Participation in New York PHP http://www.nyphp.org/show_participation.php
