RE: Ajax Back/Forward History problem - saving document state by document.save()

Mark Birbeck wrote:

> Vladimir,
> 
> > But it doesn't necessary mean that undo should be performed using
> > browser's "Back" button.
> 
> That's true, but I'm hoping that it can be an event that can be
> registered for, and than either allowed through, or acted on and
> cancelled.

*Lurk off* and forgive me if these have already been mentioned.

Is it possible that the difference between "back" actions that do and do
not "undo" be determined by the GET or POST method of the asynchronous
data request associated with each state? It seems to me this is the same
kind of state control available in the regular HTTP request/response
model, so a document.save state associated with a GET should re-request
that data (either from the local cache or a new server request) and a
POST should not be reinitialized without user confirmation.

Alternately, what if the document.save method saved a "State ID" with it
that was passed back to the JavaScript interpreter through the "back"
event? This way, the exact DOM state or variable state could be handled
by the script and the server session, rather than leaving the user agent
to guess what information the application developer intended to be
saved. There would be no need to "cancel" the event; the application
could determine what should be done with that particular "State ID" and
keep the UA from needing to maintain massive amounts of mostly
insignificant state data.

Thoughts?

-- 
James Craig
Senior Design Technologist
frog design, inc.

Received on Tuesday, 10 January 2006 09:46:26 UTC