[Seaside] Making a store in Seaside

Jason Johnson jbjohns at libsource.com
Wed Sep 12 05:48:23 UTC 2007

Hello all,

I am creating a store website somewhat like the example sushi store.  
I'm sure other people must have sites like this, so my question is; what 
is the current best practice for doing the credit card part of the 

On traditional sites, you surf with normal http and when you get to the 
part of inputting the credit card you are redirected to the https part 
of the site to complete the transaction.  Is there any way to do this in 
Seaside?  The issue is, the user spends the entire time of their visit 
inputing the information about what they want to buy so this has to get 
passed to the https site somehow.  So here are the ways I thought of 
that this can be solved in order of most desirable to least desirable.

1.  Native handling.  I can just say something like:   self call: 
SecuredComponent withCart: myCart.   and the new object will be 
displayed, it just happens that it's displayed over https (this includes 
a transparent redirect as part of the component).

2.  Native handling, but different web server.  I start up a second 
Smalltalk web server that is https only and create an application that 
has a REST type interface and only does credit card transactions.  Then 
at the point where I switch to credit card mode, I actually redirect the 
user to the https web server.  This will require the https application 
to override the 2 url reading methods to allow the REST type interface.  
The http application would need to call the https like:  
https://myOtherApp/masterCard/11111.  This would mean to do the master 
card handling and retrieve the cart from magma or some other store in 
the image where the id is 11111.

3.  Native server, but 100% https.  Just write the application as the 
sushi store is and run the web server https only.  This requires the 
opening page to simply redirect to the https site immediately.  I don't 
like this solution because it will slow down the entire site.  The 
nature of shopping is that you have many more people looking then 
buying.  Having the whole site under 100% https means I can serve less 
clients at a time and the majority pays the price for the few.

4.  Native server but tunneled through some 3rd party tunneler (perhaps 
apache).  This would be more speed/clients then approach 3 but is more 
complicated to set up and still has the problems of 3, they just don't 
show up as quickly.

5.  Give up.  Prototype the site in seaside, then when all looks good 
port it to Erlang Yaws so that I can at least maintain a homogeneous 
solution that is almost as easy to configure as a Seaside solution.  It 
will take longer to write the solution in Yaws then it would in Seaside, 
but it will come with benefits (e.g. scaling is no longer a concern, 
comes with a very nice distributed database, etc.).

6.  Big ball of mud.  Set up a big complicated apache solution with all 
kinds of URL rewriting and other such things so that the part where the 
credit card is entered is automatically put through some tunneling solution.

So, how many of these are available today, and how many of them could be 
implemented (by me if someone else isn't already doing it) in the near term?


More information about the seaside mailing list