Re: Ajax Back/Forward History problem document state by document.save()

kenny heaton wrote:
> 
> I guess what I am getting at is maybe we do not need more tools to
> help us develop dynamic application and not break the back button.
> Maybe we just need to be smart about the way we design and develop our
> applications, and a set of best practices perhaps. Maybe if you create
> a web app that "breaks the back button", and your users are still
> trying to click the back button, them maybe you need to re-look at the
> way you created and designed your application? Better web application
> usability.
> 
> I wonder what everyone thinks of that, or do web developers really
> need the ability to save the state of a page into history so the user
> can go back to it?

I think we shouldn't mix up the two case of the use of a browser : the 
navigation throw web pages, and the use of a web application. After all, 
a web application is like any other software : the user do some actions, 
and he wants to undo/redo its action in this web app.

I think that all users actions (so, to summary, all DOM mutation that 
the developer do) should be stored, not in the browser history, but in 
the undo/redo stack of the browser. Then the user only need to choice 
the edit/undo or edit/redo item menu in  his browser (or hit CTRL+Z, 
CTRL+SHIFT+z) to cancel or redo an action, like in any other software. 
(the browser could display an undo/redo button in the toolbar to improve 
the accessiblity of this feature)

To store actions in the undo/redo stack, the developer should call the 
*state function. Or better, window object could have such function :

window.startBatch();
//here, some DOM modification...
window.endBatch();

startBatch() starts a "transaction". All DOM modifications are 
registered in the transaction. endBatch() store the transaction in the 
undo/redo stack. (The core of the HTML editor of Mozilla works like 
this). So the browser can cancel DOM modifications or replay them.


Laurent