Posted by Matthew Weier O'Phinney on 05/03/05 19:20

* James <jtu@esidesign.com>:
> Actually:
>
> Will there be an issue with the back button if I use 1 script to do
> all of what I posted before?

No.


> Thank you guys for the answers. I think I will go with the following approach.
>
> (A) script 1 submits to script 2 then
> (B) script 2 redirects browser back to script 1
>
> Script 1 is in charge of submitting and displaying; script 2 does the
> processing.
>
> This list is the best!
> -James
>
>
> At 2:08 AM +0000 4/27/05, Matthew Weier O'Phinney wrote:
> >* James <jtu@esidesign.com>:
>>> I apologize in advance if I'm asking basic questions...
>>>
>>> When you hit the back button, won't the browser just take the page
>>> from the cache?
>>>
>>> I haven't switched my POSTs to GETs and this is what I'm seeing.
>>> I have a list of images. There are check boxes next to the images.
>>> When the user checks images and clicks on a DELETE CHECKED link, a
>>> new list is shown (minus the ones deleted.) When the user hits the
>>> BACK button, I see the list again with checks next to the previous
>>> images marked for deletion
> >
> >By the way... the rule of thumb I think about is this:
> >* Use GET requests when you want to be able to bookmark the page --
>> i.e., when you want the behaviour repeatable. Typical example is
>> searches.
> >
> >* Use POST requests when the operation will affect the data in some way
>> that shouldn't be cached. Examples: submitting data that will be
>> stored in the database, will update a database, or will delete an
>> entry in the database.
> >
> >Because of the back button issues (namely, not all browsers treat 'back'
> >the same way), you will need to do some workarounds, typically with
> >sessions; I've mentioned these under separate cover.
> >
>>> Just in case...
>>> I tried to add the following header before any html output to force
>>> the browser to not load from the cache and it didn't work.
>>>
>>> header("Cache-Control: no-store, no-cache, must-revalidate");
> >
> >Not all browsers will actually follow these 'rules' (actually, they're
> >in the HTTP specification, but 'rule' just sounds better). Heck,
> >versions of the same browser on different platforms sometimes treat them
> >differently.
> >
> >This is why session handling techniques are a common 'fix' for bad
> >browser behaviour in these instances.
> >
> >--
> >Matthew Weier O'Phinney | WEBSITES:
> >Webmaster and IT Specialist | http://www.garden.org
> >National Gardening Association | http://www.kidsgardening.com
> >802-863-5251 x156 | http://nationalgardenmonth.org
> >mailto:matthew@garden.org | http://vermontbotanical.org
> >
> >--
> >PHP General Mailing List (http://www.php.net/)
> >To unsubscribe, visit: http://www.php.net/unsub.php
>
>


--
Matthew Weier O'Phinney | WEBSITES:
Webmaster and IT Specialist | http://www.garden.org
National Gardening Association | http://www.kidsgardening.com
802-863-5251 x156 | http://nationalgardenmonth.org
mailto:matthew@garden.org | http://vermontbotanical.org

[Back to original message]