On Jan 17, 2006, at 6:49 PM, Nigel Thorne wrote:

> Hi Guys,
>
> I have a quick question about state. Seaside apps react to the back  
> button by restoring the previous state. So if I have the counter  
> up, then click ++ then click back I get back to 0 and clicking ++  
> takes me to 1 again. I love this!
>
> If the 'click' the user performed caused a new record to be stored  
> in a database (for example), and then the user presses the back  
> button, do you ever get into a situation where the user is trying  
> to create the same record twice, or believes the changes they made  
> is now undone...
>
> I am sorry for the vaigueness of the question. I am currently stil  
> trying to get my head around how seaside integrates with  
> persistance (so.. GOODS for example)

Hi Nigel,

This is probably more a question for the Seaside list than for the  
general Squeak list, but the answer is that Seaside doesn't backtrack  
any state it hasn't been explicitly asked to backtrack.  Along with  
the execution stack, only objects that have been registered with the  
session for backtracking have their state modified (and the degree to  
which their state is modified is under their control, see  
#snapshotCopy and #restoreFromSnapshot:).  You wouldn't register a  
domain object like a database record (or at least, I've never found  
any reason to) - the user expectation wouldn't be that this state  
would rollback with the back button.  Usually you register objects  
that represent UI state, like which tab is selected on a tab panel,  
or whether a certain node in a tree is expanded, etc.

Does that help?

Avi