On 6/16/05, Max Cooper <[EMAIL PROTECTED]> wrote:
> I think this is a weird requirement, and it may be worth re-evaluating
> why you want to know this (are you fighting the technology, or
> leveraging it?).

I can explain but remember, that you asked it first ;) It will take some time :)

The point is, that I am obsessed with Back button. At best, I want
Back button be disabled. If it cannot be achieved, then when I click
Back, [stale] page should be reloaded according to current server
state, thus it would not actually be stale. At worst, when a caching
browser like Opera keeps everything in history and does not reload a
page, I would have to check for double submit using either tokens or
model data like object IDs or timestamps.

Anyway, Netscape, MSIE and Firefox behave like I want. Maybe other
browsers too, but I am on Windows, so I cannot tell how Safari or
Konqueror behave. Old Netscape, MSIE and Firefox do not accumulate
pages in the history, if location of the next page is the same, as
location of previous page. Obviously, it is not possible to maintain
same location in the interactive application simply because I need to
POST input data. Here comes trick with redirect: browser is supposed
to drop the request, which preceds redirect. So, whatever I input into
my action, I always redirect to the exact same location. Browser does
not remember about POST location which preceds redirect. It only
remembers the GET location which I redirect to. Because it is always
the same (for an action), browser thinks that it is the same page, and
does not add in to page history.

So, as long as I stay on the same action and redirect to the same
location, browser simply reloads the content but thinks that it is the
same page (it is not the same, of course). Check out this link:
http://superinterface.com/wizard/signupWizard.do Please, open it in a
separate window. I hope you do not use Opera ;) What you see is a
login dialog. URL in the address bar does not contain jsessionid, but
"New User Signup" link does, it looks something like this:
http://superinterface.com/wizard/signupWizard.do;jsessionid=987234?cmd=Init
The page was loaded with one simple GET, session was established, and
server rewrote the link to include session ID. From here you can
either click the link to sign up (GET), or try to login (POST).

If you submit with POST, wizard perfoms two-phase request (aka
Redirect-After-Post aka Post-Redirect-Get, see Struts Dialogs, it does
the same): first it submits input with POST, and here goes the session
ID from URL. Then it redirects and loads the page. After redirect,
server already knows that browser supports cookies, so it does not
append session ID to URL. URL is clean now, browser "forgot" about
POST request because of redirect, so session ID never appears in the
address bar and never affects browser history. See, that Back button
is not enabled?

What if you clicked the "New User Signup" link instead? When page is
loaded for the first time, the link is rewritten and contains session
ID. When you click it, it is sent to the server using GET, but this
actually does not hurt, because the link contains the command to
initialize the wizard. Commands are treated by wizard in the same way
as POST requests, they are inputs. So, application redirects in the
same way as for POST request, and it comes cleaned up.

So, in this particular application everything is great, and session ID
does not mess things up. See, that Back button is not enabled! This
happened simply because page history is empty, er, it contains only
one page: signupWizard.do. Browser does not know that I serve a bunch
of different pages from this address. Until you get to the user page,
which is served by a separate action, Back button is not enabled and
you simply cannot "go back" and see stale page and resubmit it. This
is cool not only because you cannot resubmit a stale page (I need to
check for stale page anyway, because not all browsers behave like MSIE
and Firefox), but because you get the feeling of desktop application.
If you messed up with login five times, you do not need to click Back
button five times to get to the previous page. Because in a regular
application it won't be previous page, it will be five pages down in
the browser session history.

This was just a preface ;-))) Now, I have another example where it
does not work, here:
http://superinterface.com/strutsdialog/allsamples.html
If you open browser anew, and go to Login Dialog (init) link, you'll
see, that when session is established, address bar shows session ID.
So, next time I submit or reload the same action, I get a different
URL, that is, without session ID. This is different enough for browser
to create a new entry in the session history. I want to detect that
session ID is in URL, and to do a second redirect, only once, on
startup.

Hopefully you managed to read all this and tried the examples ;-)
Point is, that on Opera my applications behave the same as other. No,
actually, still better, because I can reload a page without resubmit.
But Back button sucks like in other apps, and pages are accumulated in
the history. But on MSIE and Firefox it is a completely different
experience. Not Ajax, but close. And, speaking about Ajax. This
two-phase input processing (aka Redirect-After-Post) still makes
sense, because the idea remains: "When receiving GET, render a page
(or control) according to its current server state". Many ajax pages
currently cannot be reloaded, they lose data, and ajax components dont
know what to do. My Ajax pages can be easily reloaded (I tested, of
course), though it is not really needed, but if someone clicked
Reload, it would work.

Whoa, I put down a one huge email. Hopefully, this cleans things up for you :))

Michael.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to