Awhile back, I did a brief introduction of servlets in Cincom Smalltalk. I thought I'd take a brief look at the other side of that - the SSP pages themselves. SSP pages can be written with jsp tags, which is nice for developers who are already familiar with that - you just create Smalltalk code on the back end that matches the tags.

That's not what I wanted to talk about though - when I create SSP pages (like the ones for this blog), I just embed Smalltalk code in the page. Now, you can quickly go down the road to hell that way - what I've done over the last year is to make the Smalltalk code on the pages be API calls into the server - on the main page, for instance, the code that grabs whatever posts that should show up looks like this:

			<div id="posts">

			<div class="watermark"></div>

				<%= saver fetchBlogCSSBasedOn: pageArgs andBlogEntry: specificBlog. %>

			</div> 

The "saver" there is a reference to the blog object itself (there's one per blog). The method being invoked determines what items to fetch, and formats them accordingly - all the logic is back in the server rather than on the page. What that means is that I've defined an API that I need to maintain, but I haven't created a huge set of code that lives in an HTML page.

Here's the cool part though - say that I make modifications, and - for whatever reason - it's not working quite right in my test environment. Well - I can slap a breakpoint into the API method, and run into the debugger:

That lets me walk into the debugger at the point of the API call and see what's happening. It looks like this (click the image for a bigger image):

If you get the bigger image, notice that second line, which reads "unbound method"? That's the web page itself - in Cincom Smalltalk, that comes across as code akin to workspace code - i.e., fully debuggable. This is part of what makes Smalltalk such a nice choice for web applications - you don't need a whole peripheral set of tools in order to debug them - you just do what you normally do, using the same tools that you use when creating any other kind of Smalltalk code.

That's the power of Smalltalk - consistency and simplicity.