[Seaside] Seaside 2.3 questions

[Avi Bryant]

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.