|
|
Posted by James on 05/03/05 00:01
Actually:
Will there be an issue with the back button if I use 1 script to do
all of what I posted before?
So...
Script 1 submits to itself...it does the processing, updates
databases, etc...then it redirects back to itself for displaying for
results.
-James
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
--
-James
Navigation:
[Reply to this message]
|