Avi Bryant <avi at beta4.com> wrote:
> On Tue, 3 Sep 2002 goran.hultgren at bluefish.se wrote:
> 
> > 1. Seaside. See http://swiki.squeakfoundation.org/sea
> >
> > Haven't used it myself but Avi Bryant can tell you more and it looks
> > good. Fairly conventional approach (at least compared to number 2
> > below).
> 
> Conventional?  Can you elaborate on this?  To my mind, the main

Well, I was referring to your use of template files (similar to ASP/JSP
I guess) and your mentioning sometime that it was modelled after
WebObjects, which I thought was rather conventional - but that was just
my impression without having used it myself.

> distinguishing feature of Seaside is its highly un-conventional use of
> continuations to model control flow.  Typically, in web development, each

Yes, I agree that *that* is not "conventional". Sorry for that.

> request/response is an isolated piece of code, with only crude
> paramterized GOTOs (usually in the form of links to named URLs)
> transitioning between them.  In Seaside, moving to another page is modeled
> as a subroutine call, with a return value.  This means, among other
> advantages, that multi-page processes can be described in a single
> method; for example,
> 
> customer := self getCustomerInfo.
> payment := self getPaymentInfoFor: customer.
> (self processPayment: payment forCustomer: customer)
>   whileFalse: [payment := self getAlternatePaymentInfoFor: customer].
> self displaySuccessPage.
> 
> might trigger a sequence of pages in a shopping cart application.

Yep, sounds cool indeed.

> By comparison, my understanding was that HttpView is intentionally
> conventional and light-weight in its approach to session management.

Well, yes, the session management is conventional. I mean, I don't do
anything else than keep track of the user by a cookie - otherwise it is
(currently) stateless on the serverside.

> What's somewhat unusual about it is its approach to HTML generation, which
> is purely programmatic rather than template based.

Right. And it's widget metaphor for Forms - I am very pleased with how
that worked out (And the url mapping directly to methods in the view
classes). Essentially you can describe a webpage with a Form and it's
server action in one single method:

b - self builder.
b start; h1: 'Your name please';postForm.
namefield _ b html: 'Name: '; inputText.
namevar _ b html: 'Your name is: '; var.
b endForm; end.
b ifPost: [namevar value: namefield value]
^b

(this is unrun pseudocode but this should work). The interesting part is
the #inputText message returning a widget which can be called with
value:/value to set/get its content. #var embeds a variable in the page.

One neat thing is that this also works for all Form elements and you
don't need to name them or give them ids etc.

> Goran, you might be interested in the work I've been doing towards Seaside
> 2.0 - the lower layers, which are more or less complete, take a
> programmatic approach somewhat similar to HttpView, although within the
> continuation based session model (the higher layers will re-introduce a
> template system).  You can grab a snapshot at
> 
> http://beta4.com/squeak/aubergines/source/Borges.st

I will take a look if/when I get time. :-) I have also been thinking
about possibility of combining HttpView with Seaside, but I don't know
if that is easy.

I am sorry if I made it sound that Seaside is conventional as in boring,
it is most definitely not. :-)

regards, Göran