Thank you. Jon - we await a reply! ;) > -----Original Message----- > From: Eric Dobbs [mailto:[EMAIL PROTECTED]] > Sent: 18 January 2002 17:04 > To: Turbine Developers List > Subject: Re: Redirects > > > > On Friday, January 18, 2002, at 02:38 AM, Gareth Coltman wrote: > > > - User logs in. (URL: /Login.vm) > > - User clicks on login button (URL: /action/Login) > > - Template is set to Homepage.vm (URL would still be /Login.vm) > > - User goes elsewhere in the site > > - User returns to homepage by using browser's back button. > > (Eventually returning user to /action/Login and causing the action to be > > performed again) > ... > > But imagine if this was a delete action. > > > > This is why I think a redirect can be useful. > > Agreed that redirects can be useful. > > We have several pages where backend processing effects status values > displayed on the page. The user hits the refresh button, or in the > future we may add a meta tag to periodically refresh. On refresh the > actions are re-executed. > > We started by including logic to detect the session counters (the > "recommended" solution) to suppress the redundant action. But users > wanted to be able to use their back button and resubmit forms to ease > the data entry when adding similar records. From their point of view > our webapp was breaking a basic feature of the browser. We replaced > the session counter logic with redirects. This protects from > redundant entries from refresh (and back buttons as Gareth notes) and > allows the a feature of the browser to ease data entry. And added > bonus, it made our code just slightly easier to follow. > > That set of benefits was worth the cost of extra network activity for > the redirect. > > -Eric > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > >
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
