is this possible?

**MeerKat** · Jul 16 '05, 10:59 PM

Re: is this possible?

If a page was generated with a POST, then any refreshes of that page
will cause the browser to repost the data and cause the message to
appear. There's nothing you can do about that.

To solve your 'cancel' button scenario problem, you could us a <a
href=""> link to return to the home page instead of using a form
submission. You could style up the link using CSS to make it look like a
button if thats the effect you want.

Thats all the help i can offer :)

MK.

dan glenn wrote:
[color=blue]
> I have a php page which serves up multiple pages based on how the user
> interacts with it - there are links on the first page that will reload (from
> the same php file) a new page with form fields and submit buttons, and when
> a user posts from that new page (or cancels), then the same php file is
> again loaded, detecting how the user responded and generating the
> appropriate html for whatever should be none next. All very typical.
>
> What I want to know is, is there a way so that once a user has posted from
> some submit button from one page (we'll say he Cancel's from a page that had
> a form Cancel button so he returns to the original non-form default page
> generated from the php file), can it be made so if the user then "refreshes"
> the new page (hits the Refresh or Reload browser button) he does NOT get the
> browser's "The page cannot be refreshed without resending the information.
> Click Retry to send the information again, or click Cancel to return to the
> page that you were trying to view." dialog? In other words, what I'd like is
> a way to have the browser think that there was no posting done (even though
> there was) once I've generated this certain 'home' page with my php code, so
> that user ReLoad's of the page won't get this warning.
>
> This is probably related also to problems I've had with "breaking the BACK
> button" on sequences of php pages: if the user BACK's up to a page that was
> generated by a post, it may not even be possible to regenerate the original
> page. What's the best way of handling these situations??
>
> -dg
>
>[/color]

--
MeerKat

**André Næss** · Jul 16 '05, 10:59 PM

Re: is this possible?

dan glenn:
[color=blue]
> I have a php page which serves up multiple pages based on how the user
> interacts with it - there are links on the first page that will reload
> (from the same php file) a new page with form fields and submit buttons,
> and when a user posts from that new page (or cancels), then the same php
> file is again loaded, detecting how the user responded and generating the
> appropriate html for whatever should be none next. All very typical.
>
> What I want to know is, is there a way so that once a user has posted from
> some submit button from one page (we'll say he Cancel's from a page that
> had a form Cancel button so he returns to the original non-form default
> page generated from the php file), can it be made so if the user then
> "refreshes" the new page (hits the Refresh or Reload browser button) he
> does NOT get the browser's "The page cannot be refreshed without resending
> the information. Click Retry to send the information again, or click
> Cancel to return to the page that you were trying to view." dialog? In
> other words, what I'd like is a way to have the browser think that there
> was no posting done (even though there was) once I've generated this
> certain 'home' page with my php code, so that user ReLoad's of the page
> won't get this warning.
>[/color]

The simplest way is to use header("Locatio n:<url>"). When for example the
user hits cancel, you call that function and send him to where he should
go. This is a general solution which can be applied whenever you need to
process POST data and then return a page that can still be refreshed. It
also fixes the problem of "double posting".
[color=blue]
> This is probably related also to problems I've had with "breaking the BACK
> button" on sequences of php pages: if the user BACK's up to a page that
> was generated by a post, it may not even be possible to regenerate the
> original page. What's the best way of handling these situations??[/color]

Well if the page was actually generated based on POST data there is nothing
you can do, and the user simply chooses whether to repost or not. It
depends on the situation so I can't really give you a clearer answer. In my
applications however I've always been able to avoid the pesky "page was
generated from a post request", so it shouldn't be too hard.

André Næss

**MeerKat** · Jul 16 '05, 10:59 PM

Re: is this possible?

André Næss wrote:
[color=blue]
> dan glenn:
>
>[color=green]
>>I have a php page which serves up multiple pages based on how the user
>>interacts with it - there are links on the first page that will reload
>>(from the same php file) a new page with form fields and submit buttons,
>>and when a user posts from that new page (or cancels), then the same php
>>file is again loaded, detecting how the user responded and generating the
>>appropriate html for whatever should be none next. All very typical.
>>
>>What I want to know is, is there a way so that once a user has posted from
>>some submit button from one page (we'll say he Cancel's from a page that
>>had a form Cancel button so he returns to the original non-form default
>>page generated from the php file), can it be made so if the user then
>>"refreshes" the new page (hits the Refresh or Reload browser button) he
>>does NOT get the browser's "The page cannot be refreshed without resending
>>the information. Click Retry to send the information again, or click
>>Cancel to return to the page that you were trying to view." dialog? In
>>other words, what I'd like is a way to have the browser think that there
>>was no posting done (even though there was) once I've generated this
>>certain 'home' page with my php code, so that user ReLoad's of the page
>>won't get this warning.
>>[/color]
> The simplest way is to use header("Locatio n:<url>"). When for example the
> user hits cancel, you call that function and send him to where he should
> go. This is a general solution which can be applied whenever you need to
> process POST data and then return a page that can still be refreshed. It
> also fixes the problem of "double posting".[/color]

So, when a user clicks 'cancel', you are still POSTing to the same url,
which detects that cancel has been pressed and then redirects to itself?
Is this right?
[color=blue][color=green]
>>This is probably related also to problems I've had with "breaking the BACK
>>button" on sequences of php pages: if the user BACK's up to a page that
>>was generated by a post, it may not even be possible to regenerate the
>>original page. What's the best way of handling these situations??[/color]
>
>
> Well if the page was actually generated based on POST data there is nothing
> you can do, and the user simply chooses whether to repost or not. It
> depends on the situation so I can't really give you a clearer answer. In my
> applications however I've always been able to avoid the pesky "page was
> generated from a post request", so it shouldn't be too hard.
>
> André Næss[/color]

--
MeerKat

is this possible?

is this possible?

Comment

Comment

Comment