
Seaside 3.0 released - pietrofmaggi
http://seaside.st/community/development/seaside30
======
johnwatson11218
I saw a demo of Seaside a few years ago where they were using continuations to
write code like

    
    
       while( updateBillingInfo() != 'done' ){
           displayUpdateBillingInfo();
       }
       renderCheckoutScreen();
       ....
    
    
    

The point was that a method call that might present output to a user or read
in a value could be an entire http render/response cycle. The
'updateBillingInfo()' method above could include arbitrary web interaction
with the user. What was allowing all this was the fact that the framework was
using continuations. So that when the user was finished updating the billing
info the stack of the above code could be revived and resumed.

I thought it was so cool to be able to structure complex web interaction with
that kind of procedural code. The closest thing I've seen at work is srping
webflow but that is nowhere near as cool.

For years we have been able to inject a password prompt to a user when they
request a secured resource. After the user logs in they can go to the secured
page. What about something like a multipage color chooser? so that at any
point in a web interaction the user can go into the color chooser sequence of
screens and have the end result returned to wherever they were when it kicked
off? And being able to stack these re-usable flows arbitrarily deep?

What I have seen in production is some kind of hack like a 'returnTo' http
parameter that lets the other flow know where to send the user when they
finish that part of the interaction. In some cases you see people attempt 2
levels by passing the parent and grandparent as a string or something like
that. The thing is that there is no way I would dive into smalltalk to get
features like this. For better or worse I am tied to Java on the server side.

~~~
lolipop1
At the end of the day, how do you implement scalable multi-threaded
continuations? Yes the code has a better allure, but it's not exactly hard to
add parameters to http requests.

Having used a few frameworks, I can tell you it's also easier to debug code
that's closer to http requests. Being able to simply look at what's being
passed in a simple way and understand everything instantaneously is a big
advantage. Actually, this argument is more about the tools at hand, but there
are definitively more and better tools to analyze http requests than anything
else.

~~~
johnwatson11218
yea I hear you. The problem I have will passing the http parameters is that it
only goes one level deep. If you want to nest it arbitrarily you would have to
build up a comma separated list of values to refer to all the places you need
to return to. At that point, if you think of this list of return places as a
set of pointers it is as if you are implementing a stack. Having this kind of
thing as a first class construct could maybe allow this to be checked by the
compiler.

To be honest the details of implementing 'scalable multi-threaded
continuations' is beyond my skill level.

------
jcromartie
I really love Seaside, and I am still as amazed by it today as the day I saw
it. But I just can't justify being "isolated" inside of the Smalltalk VM.
There's just too much wheel-reinventing required to build a major web app in
Smalltalk. The libraries are a dealbreaker and that's really too bad, because
programming in Smalltalk is amazing.

~~~
fractallyte
Just curious: what do you mean by 'wheel-reinventing' and 'libraries are a
dealbreaker'?

Smalltalk contains a comprehensive set of classes, and Seaside has 'out-of-
the-box' support for Scriptaculous and JQuery, and has numerous examples of
web app components...

As for the 'isolation' within a Smalltalk VM: isn't a virtualised environment
actually beneficial for scalability?

~~~
jcromartie
When you develop a web app in Rails and you hit a snag you can usually solve
it by grabbing a Gem or a Rails plugin. Similarly, if you need to do something
in Java there is most likely a good mature library out there already, and you
can just drop a Jarfile in your project and go.

I'm talking about all the odd little things you end up doing in web apps, like
drawing charts or parsing PDFs or talking to some obscure web service. You'd
be left to solve these things on your own with Smalltalk (although solving
them may be easier).

~~~
gnaritas
That's not really true because you can always shell out Linux and do that
chunk of work in some other language. You're not trapped in Smalltalk. I've
used ImageMagick and Markdown in a Seaside app without issue.

