[Seaside] Tutorial completed: cool

[Avi Bryant]

On Tue, 26 Feb 2002, Marcel Weiher wrote:

> Yes.  Another one to override would be ^html to read WO-templates from
> disk...

Not that this bears directly on what we were talking about, but you can
read templates from disk by overriding #template to return an
IAFileTemplate -

template
  ^ IAFileTemplate new
       file: 'foo.html';
       bindWith: [:template | self addBindingsTo: template]

> Yes.  My basic requirement (both for my particular application and on
> philosophical grounds ;-) is that the source-document not be modified in
> any way.  This makes the mapping significantly more difficult, but makes
> a huge difference in interoperability, with fairly deep consequences.

I definitely agree on philosophical grounds, although I think a continuum
is useful from totally unmodified source-document to, in simple cases,
source document modified enough to have no need for external mapping
(hence all the emphasis in Seaside on default bindings).  That's a fuzzy
line, of course, because it depends on how you define "simple cases" and
how much modification you're willing to stomach in the worst case.

Dealing with PDF and PS documents is of course a whole different game,
since it's unlikely the developer is going to write these by hand, and so
all the developer-friendly shortcuts and defaults make much less sense.

> Highly realistic, and highly useful!  I used to work on a content
> management system written in Objective-C, but with our own web-libs.  We
> started off with a session-based concept, but later managed to migrate
> to a a technique we called 'micro-transactions'.  Most of the app was
> 'stateless' in the sense of not having a session and every page access
> being self-contained.  Only when you edited a particular piece of
> information did we generate a tiny session, which usually lasted for 1-3
> page-views, and which discardeed immediately after you were done with
> the transaction.

Hmm, that's very interesting.  Not so different from Seaside's current
notion of transactions, except that in Seaside you're always in one.

How do you make the transition from stateless to stateful?  More
concretely - are the urls generated on a stateless page always stateless
urls?  In which case you have stateful pages that initialize themselves
from stateless urls and then switch into stateful mode?

My main concern with statelessness is that it leads to much more
convoluted control flow.  Seaside pages carry around their continuation,
which is a *lot* easier to persist as server-side state than as
client-side state.  If you lose that, you're back to simple GOTOs
everywhere, and I don't consider that a win.

> Once again, I am not sure if this is feasible or that it will actually
> be useful, though I strongly suspect it will (our system was not
> transparent, but the small extra effort was worth it).

Worth it in which ways?  Testability?  Bookmarkability?  Low memory
overhead?

> So I am not
> asking that Seaside actually do this, but just dreaming along.

Sure, but I find it interesting to explore anyway.

Cheers,
Avi