[Seaside] expiring pages

[Julian Fitzell]

radoslav hodnicak wrote:
> I have another problem now, and that is how to detect if the control flow
> "escaped" from #isolate: block (or something similar). For users'
> convenience, I've split some larger forms to several separate smaller
> forms. However now it happens that when they use the back button before
> completing the whole series of edit pages the object stays partially
> changed. Example
> 
> ViewerComponent
>  item1
>  item2
> 
> click on item1 => session isolate: [self call: (EditComponent on: item1)]
> 
> EditComponent on item1
>  edit form 1 => edit form 2 => ... => final form with save/cancel
> 
> 
> now, user gets to form 2, the properties from form 1 are already changed
> in item1. user uses back button to get to Viewer page and starts to edit
> item2. I'm stuck with half-changed item1.
> 
> Is there a way to do something so that the old isolate block gets
> completed/cancelled/whatever and I can rollback a transaction there?

Ok, well #isolate: is not really transactional, it merely groups and 
expires pages.  The only way seaside could deal with reverting that data 
is if you made it back-trackable, but you don't want to do that with 
model objects.

So, other options?  You can try to use your database's transactions 
(some people have played with having database transactions match up with 
#isolate: blocks).  But what I do is to have a read-through proxy for 
the object.  It uses #doesNotUnderstand to call any accessors through to 
the real object but when you call a setter it caches the data locally 
and only pushes those through when you tell it to write.  This is made 
very easy in our case because we have a meta-model that describes our 
model objects and thus makes it clear which methods are variable 
setters, etc.  In the general case, without such a meta-model, this 
would be harder.

Anyway, hopefully that gives you a few places to start thinking...

Julian