[Seaside] Seaside philosophy and real life implementations

[Avi Bryant]

On Thu, 13 Jan 2005 22:57:53 +0100, barger <barger at barnet.sk> wrote:

> There should be possibility to serve :
> 1, static content ( from files - this is easy by KomHttp, ModuleAssembly,
> alias and plugin scheme as i found )
> 2, dynamic content ( any object from image should be able to answer http
> requests - like in Gollman web server, by extending basic Object class, any
> object can handle requests. )
> 3, session oriented content ( when serialization, transaction or remote
> coding is needed - seaside is perfect solution ) 

Barger,

I think you've actually got a pretty good handle on "the Seaside
philosophy" - (3) is definitely the focus, and (1) and (2) are,
generally, left for other servers.  The interesting value Seaside adds
is in dealing with sessions, and anything that is explicitly
sessionless/stateless should really be done with some other tool.  The
reason for that is that, at least as far as I've been able to figure
out, this is an all-or-nothing choice per application:  either you use
sessions or you don't.  If you do use sessions, you might as well use
them as fully as possible (which is one way of summarizing Seaside's
philosophy); if you don't, nothing in the Seaside framework is going
to help you.

So instead, we've tried to find some ways to get the advantages of
sessionless apps (like bookmarking and static indexing, as you point
out) even within the context of sessions.  Janus is probably the best
example of this.  Yes, it's inelegant, but it's the best we've come up
with so far.

However, if you do want to use Seaside to do something like what the
Gollman server does, you don't actually have to subclass
WAApplication.  You can register any WARequestHandler with a Seaside
application, as if it were a session - so it'll have a unique ID that
will map to it (this is done for static documents like CSS "files" for
example).  And the protocol that WARequestHandler implements is
actually quite small: #handleRequest:, #isActive, and #unregistered. 
So if you implement those on your objects you'll be fine.  Use
#urlForRequestHandler: to get a permanent URL for it.

HTH,
Avi