[Seaside] Seaside 2.3 questions

[Derek Brans]

Thanks Avi.  That was so helpful.
Derek Brans
Nerd on a Wire
Web design that's anything but square
http://www.nerdonawire.com
phone: 604.874.6463
mailto: brans at nerdonawire.com

----- Original Message -----
From: "Avi Bryant" <avi at beta4.com>
To: "The Squeak Enterprise Aubergines Server - general discussion."
<seaside at lists.squeakfoundation.org>
Sent: Tuesday, April 08, 2003 11:58 AM
Subject: Re: [Seaside] Seaside 2.3 questions


>
> On Mon, 7 Apr 2003, Derek Brans wrote:
>
> > WARegistry seems to have just done away with the session cache.  Can we
> > still have application-specific session expiration rules?
>
> Yes.  The idea is that each session (or rather, each request handler) gets
> sent #isActive (I think that's the right selector, don't have the code in
> front of me) periodically, and those that respond false are cleared out.
> So you can implement whatever expiration scheme you like on an instance by
> instance basis.
>
> > Which example seaside applications are the best examples of 2.3 - style
> > programming?
>
> None of them, I'm afraid.  I will probably rewrite the SM
> example to be more idiomatic 2.3 (use Task, for example).
>
> > What's the best way to do the following in 2.3
> > 1. Insert code to determine the entry point based on the path
> > (used to be "unhandled request")
>
> Override #rootController in WAControllerSession.  Look at the 'path'
> instance variable to decide what to return.
>
> > 2. pass on POST values from a non-seaside form to an entrypoint
>
> You should probably play with creating a subclass of WAApplication and
> overriding #handleRequest:.
>
> To be honest I don't yet have a clear picture of what the best ways of
> doing that are - there are plenty of hooks for games of that kind, but
> you'll have to experiment to find out what works best for your particular
> needs.
>
> > What is a WATask?  It seems to be a controllor that encapsulates a
> > method "go" that calls other components to render themselves.  In its
> > rendering it does something I don't understand and uses
> > WASimulatedRequestNotification.
>
> The point of task is to have something that acts exactly like a Component
> (in terms of call/answer and embedding), but that encapuslates a process
> rather than a particular piece of UI - ie, all it does is call a bunch of
> other components.  You'll notice that, for example, WATransactionTest used
> to need a "go" link that it showed first, which kicked off the real test.
> Since it's now a WATask, there's no need for that extra step.  This is
> true even when it's embedded (as it is in WATestTabs).
>
> The theoretical implementation of Task is that it's a component that
> renders itself by responding with a redirect to its #go action method.  So
> whenever you try to render it you get jumped to #go immediately.
>
> The actual implementation is optimized, in that it uses that
> SimulatedRequestNotification to skip the extra response/request involved
> in that redirect.
>
> Note that this absolutely requires that #renderOn: etc methods are
> side-effect free, since that notifcation can stop and restart
> rendering at any point.
>
> > I forget if there was a change in heart as to where stuff like database
> > connection should reside for the components to access.  Was that still
> > in the Session object?
>
> That hasn't changed.
>
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside
>