[Seaside] #call: #answer / sessions
mbany at cincom.com
Fri Jan 19 11:55:05 UTC 2007
Found at http://localhost:8080/seaside/faq (SeasideFAQ package)
It is sometimes necessary to subclass WASession. Typical situations for subclassing WASession.
- Need to clean-up external resources when Seaside session expires (reimplement #unregistered)
- Need to attach some data to the Seaside session using additional instance variables
- Need to include additional behavior, statistics, monitoring (reimplement #responseForRequest:)
Seaside applications are assigned their session class using the "config" application ("Session Class" field).
It can also be set programmatically
app preferenceAt: #sessionClass put: MySession
> -----Original Message-----
> From: seaside-bounces at lists.squeakfoundation.org
> [mailto:seaside-bounces at lists.squeakfoundation.org] On Behalf
> Of Ramiro Diaz Trepat
> Sent: vendredi, 19. janvier 2007 03:28
> To: The Squeak Enterprise Aubergines Server - general discussion.
> Subject: Re: [Seaside] #call: #answer / sessions
> > > When you develop a login process, like the one in Ramon's blog.
> > > Where is it proper to store the user that is logged on? Is this
> > > supposed to be stored somewhere in the WASession?
> > Yes, a custom session class is a good place for this, so
> you can have
> > access to it from every component with a simple..
> > self session currentUser
> > Also common is
> > self session database
> If I create a subclass of WASession with the currentUser
> attribute, how do I inform Seaside to use it when I call self
> session? For it not to pass me a regular WASession Thank you
> very much for answering Ramón.
> By the way, the work you have been doing with onsmalltalk.com
> is great, particularly for noobs like me.
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
More information about the Seaside