Seaside 3.0 released
seaside.st
seaside.st
while( updateBillingInfo() != 'done' ){
displayUpdateBillingInfo();
}
renderCheckoutScreen();
....
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.
Another thing is that in my personal programming the server side isn't really where I hurt the most. Currently I'm more interested in client side stuff. I am learning Flex and ActionScript at the moment in order to convert some code I did in javascript/ajax to Flex.
http://www.lmcalpin.com/post/1109835129/dev-derby-2010
They did it using the Play Framework in pure Java. Incidentally the Play framework supports Scala, but this example goes on to show that Java is'nt quite out of the game yet.
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.
To be honest the details of implementing 'scalable multi-threaded continuations' is beyond my skill level.
Coroutines are an interesting lighter alternative (though will still suffer from threading & session affinity issues).
See coro based libraries/frameworks influenced by Seaside like Continuity (http://continuity.tlt42.org/) & Nagare (http://www.nagare.org/) (which I think uses coros?).
Here is a fulling working Continuity example:
use strict;
use warnings;
use Continuity;
use HTML::AsSubs;
Continuity->new->loop;
sub main {
my $r = shift;
###########################################
# helpers
my $update_billing_info = sub {
return 1 if eval { $r->param('updated') };
return;
};
my $display_update_billing_info = sub {
$r->print(
form(
input( {type => 'checkbox', name => 'updated'}, 'updated?' ),
br,
input( {type => 'submit'} ),
p( "No. of tries thus far - $_[0]" ),
)->as_HTML
);
};
my $render_checkout_screen = sub {$r->print("Updated after $_[0] submits!")};
###########################################
# business logic
my $count_tries;
while (not $update_billing_info->()) {
$display_update_billing_info->( $count_tries++ );
$r->next;
}
$render_checkout_screen->( $count_tries );
}https://docs.google.com/present/view?id=dcbpz3ck_24f3v83ggz&...
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?
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).