[Seaside] Re: Problems with expire in Seaside

Avi Bryant avi at beta4.com
Fri Aug 27 16:28:04 CEST 2004


(Replying on-list so that others can benefit from the question)

> Hi.
> I've searched for this problem on the web but haven't found any 
> solutions so i was hoping that maybe you could give me a hint.
>
> I'm calling my Seaside application with a query parameter specifying 
> which company database it should access 
> (http://localhost:9090/seaside/app?site=1111111111).
> The problem is that when a page expires, Seaside redirects to 
> 'http://localhost:9090/seaside/app' which makes it impossible to login 
> again.
> Is there any way to alter the WAApplication's baseUrl from the code to 
> include the parameter? Or any way to override the default 
> expire-behaviour?

That's a tricky one - the whole point of expiring a session is to free 
up the memory associated with it, and so there's nowhere to maintain 
the state of which particular site that session was for.  And it does 
need to be session-specific - you don't want to alter the application's 
base URL because that will affect all sessions in that application at 
once.  It seems like maybe we want a mechanism almost like finalization 
in garbage collection, where the session itself doesn't stick around 
but is optionally replaced by some other, smaller object that stores a 
few pieces of info about the session (like, in your case, the site 
number), and gets control if any further requests come in for that 
session.  It can then display the right message, do the appropriate 
redirect, etc.  Can someone think of an appropriate name for this 
object?  A "forwarder", maybe?  (as in, the session is gone but it left 
a forwarding address).  The Forwarder should expire too, but after a 
much longer period of time than the session.

This shouldn't be too hard to implement - it'll just take some messing 
around in #unregisterExpiredHandlers so that you send #forwarder to 
anything that's expired, and throw the result (if non-nil) into the new 
keysByHandler and handlersByKey dicts, using the same key as the 
expired handler its replacing.  Then put a default #forwarder method 
that returns nil onto WARequestHandler, and override it on your session 
subclass to return a custom forwarder object.  This will get sent 
#handleRequest: (and be expected to return a WAResponse) if any 
requests are sent to that session once its expired, and it can do 
whatever it likes from there.  Just make sure it doesn't keep a 
reference to the whole session object, which would defeat the purpose.  
You'll also need an #isActive method (quick and dirty is just to return 
'true' so that the forwarder never expires).

Unless someone can point out why this is a bad idea, or unless someone 
else implements it first, I'll probably post a version of the above on 
Monday.

Cheers,
Avi



More information about the Seaside mailing list