[Borges-users] controller and delegate

[Слепнев Владимир]

>Backtracking component state and ensuring correct delegation are
>separate issues.  My example illustrated above does fail if @delegate 
>is
>not held in a StateHolder because the delegate changes out from
>underneath you, resulting in incorrect operation when the session 
>forks.
...
>You will arrive at 'ComponentB', not 'ComponentA', the component you
>left.  This will break applications, and be confusing to developers,
>since ComponentB will not expect the value that ComponentAA hands it
>when ComponentAA calls #answer.

1) Component AA hands its return value to Component A, not Component 
B. But Component A is no longer the root's delegate, so it does not 
get drawn. (But it doesn't get GC'ed and break the application, 
because it is referenced in the continuation variable, in the saved 
stack copy.) For example: if we open Component A in a separate window, 
then open Component B in a separate window, then refresh the first 
window, it will show Component B.

2) But session forking and backtracking are actually the same issue, 
we can't tell one from the other on the server side. If we want to 
easily go back to a controller's past state after we have forked the 
session, the controller should be registered for backtracking. In your 
test case, if we register the root component for backtracking, the 
problem goes away. (Or so it seems.) So, I stand where I stand; you 
decide =)) 

But once again, saving the delegate is one of the reasons SushiNet is 
hogging memory. When we hit 'browse', the main window calls the item 
list, and saves the previous delegate in 'saved'. But the previous 
delegate has a @continuation local variable, which stores its call 
stack, which stores the _then_previous_ value of the main window's 
'saved' (which is a local variable in one of the functions on the 
stack). And so on.

>Seaside has no code to prevent caching of pages.  In fact, this is
>probably something you don't want, since you will re-render the page,
>which will set up another snapshot identical to the one for that page
>you just went back to.

A good point... I think the root of the problem is that the LRUCache 
isn't a 'properly implemented' hash-set - we can store the same 
continuation/snapshot in it two times, with different keys. I could 
try to look into that, if you agree.

>This entry points to the April 3rd, 2004 post on "Modality and Magic
>Realism", is this the entry you are referring to?

Maybe the URL got screwed up somehow... =)) In my browser, it points 
to 'Attacking State', September 4, 2003.

Vladimir Slepnev