[Borges-users] controller and delegate

[Eric Hodel]

??????? ???????? (slepnev_v at rambler.ru) wrote:

> >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.

Ah yes, you are correct here.

> 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.

It won't with #delegate_to as-is.  I don't see why this would be
desirable.  If I'm at amazon.com, and I open 'books' in one window, and
'electronics' in a second window, then refresh the 'books' window, I
don't now have two 'electronics' windows.

> 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 =)) 

I dislike how this is unintuitive.  I would not like to tell authors "if
you want to behave in a natural way, you have to do X" when it can be
built in easily.

> 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'.

Seaside's SushiNet has the same issue, so I'm inclined to believe it is
just a poor coding practice.  I would rather educate authors to not
write this kind of loop.

This will fix the memory hogging problem in a much better way:

def browse
  home
  @main.call SushiNet::StoreItemList.new(session.all_items)
end

In fact, I think this is the correct fix, since StoreBrowseFrame#search
is written the same way.

My biggest problem with not holding the delegate in a StateHolder is
that Seaside uses a StateHolder to hold the delegate.  While I have come
across bitrot in Seaside, this does not seem to be a case of bitrot.

> >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.

As short as the LRUcache should be, I don't think this will be a major
problem.  If developers have their apps growing too large, this is one
of the tunables they can use to limit that growth.

> >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.

Ah, yes.  I think this is a different case because Seaside is
implemented the same way, and its not something application developers
need to know about, other than that things Just Work.

-- 
Eric Hodel - drbrain at segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E  7C11 332A 551C 796C 9F04

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/borges-users/attachments/20040419/db3e93ad/attachment.bin