is this possible?

dan glenn

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

Jul 16 '05 #1

MeerKat

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:

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

--
MeerKat

Jul 16 '05 #2

André Næss

dan glenn:

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.

The simplest way is to use header("Location:<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".
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??

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

Jul 16 '05 #3

MeerKat

André Næss wrote:

dan glenn:

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.

The simplest way is to use header("Location:<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".

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?

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??

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 #4