itsme213 wrote:
> "Michael Neumann" <mneumann / ntecs.de> wrote
> 
> 
>>Well, using live-update could change the current components state, but
>>it would not modify snapshotted state. This means, that a live-update
>>should not change state that is beeing backtracked, as a live-update
>>does not generate a new page.
> 
> 
> Is generation of a new page necessarily tied to being able to backtrack?

You need to understand what a "page" is: It's the snapshots of one state 
of the components + registered callbacks. You need the snapshots to go 
back to a particular state. And the callbacks, to make sure that you 
don't invoke a callback on a state of a components-tree for which it was 
not registered.

So it's neccessary for backtracking, but also for being able to invoke a 
callback.

> On the server: Could live_update components override
> Component#backtrack_state to have the back-button work even without
> page-reloads?

backtracking would work anyway, but not for the live_updated changes. 
but I've not yet thought too much about it, so I can't say that for 
sure. I'll have to talk to Avi on this topic, how he has solved this in 
Seaside2.

> On the client: Will the browser's history need to be manipulated to make the
> back button work with live updates?

The requests sent by the javascript has nothing to do with the 
page-history managed by the browser. So, you won't be able to use the 
browsers back-button. But I wouldn't use live-updates too extensivly. 
For some purposes it's fine, but I think it turns out to be too complex 
if you use them for everything. Keep it simple, that's my opinion.

Regards,

   Michael