Since VA Smalltalk Version 8 comes with an early alpha of Seaside 2.9 and – to make things a little more challenging – doesn’t fully support continuations yet, there are some tricky little itches to sail around when working with it.
One of the things that makes Smalltalk and Seaside cool and powerful is that you can change your code in the smalltalk debugger while your web browser is waiting for a response. You can change the rendering and business code on the fly and once you hit the resume button in your debugger you immediately see the results of your changes in the web browser – without restarting or redeploying anything or breaking your fingers fighting some xml configurations. This alone sums up to quite a few days of productivity gain in comparison to other web application technologies.
Unfortunately, out of the box, this doesn’t really work in VAST. Most of the time, when an exception occurs, your browser will simple get an HTTP 500 Internal Server Error.
But that’s something that can be changed. You simply need to do some changes in your image, some of them related to SST (Server Smalltalk, the frontend web server component within your Smalltalk image), and some related to Seaside.
Let’s start by keeping SST from handling backend errors by returning HTTP 500 codes to the browser. The configuration of SST out of the box makes sense in a deployed app, where you may want to answer some error to the browser instead of boring your users with details they neither can do anything about nor are likely to understand.
To change this setting, go to your Transcript window, choose “Trap Exceptions…” from the Tools->SST menu and dosable at least trapping of http and/or https exceptions. You should do the same in the dialog Tools->SST->Forward Exceptions…
I know one of these two usually is enough, but I constantly forget and therefore ignore which one it is 😉
Now SST doesn’t get in our way when a Seaside routine fails.
But still, the effect is one of two possible scenarios: Your image freezes and the browser is waiting for a response forever or your browser simply gives you a short error description, just as you would get it in yourSmalltalk debugger. But there is no way of opening a debugger on the erronous code.
This is the “fault” of the Seaside Configuration as it ships in VAST. You can of course change that. You can configure a Seaside Application to handle errors in several ways. For example, you can simply show an error page, either one that you provide or one that comes with Seaside. There also is an option to show the stack trace in the browser and in other Smalltalk implementations the stack trace page has a link at the top saying debug. When you click it, the Smalltalk debugger is opened. This feature, however depends on Contiuations to work and therefor is not available in VAST 8.
Another option is that the Smalltalk debugger is opened immediately, and the browser gets no response. This means the Browser is waiting for a response that will not arrive before you take action in the Smalltalk image. This, by the way, is also the preferred behaviour if you want to use Breakpoints to step through your code. Once you resume after changing code or simply watching what goes on, the browser will get its response.
To change the configuration of your Seaside Application, navigate to the Configuration Page of your Application, either by surfing to localhost:xxxx/seaside/config and clicking on the link for your app or by using the “config” option at the bottom bar of your app in the web browser. The configuration parameter you want to change can be found in the “Filters” section of the Configuration page. It’s pretty likely there is a WAExceptionFilter setting which can be configured. Click on Configure and you will be presented another configuration screen.
The Ancestry Section should include “WAExceptionFilterConfiguration” If it doesn’t, add it. If it is added, you can change the Exception Handler Setting. Seaside seems to use WAHtmlErrorHandler by default. You should override this setting and use WADebugErrorHandler instead.
You can try the others as well, but the one I find must useful is WADebugErrorHandler, because it gives me maximum control.
Joachims Small World 