Seaside versus Aida

The Aida 6 web framework is rather different in objectives than Seaside 3 as a Smalltalk application server. My specific interest was to determine to what extent the services for web applications were orthogonal to any given web markup.  Both default to HTML but I am looking at frameworks suitable for emitting declarative Curl markup using the Curl web content language (originally MIT and now Sumisho.)

Both frameworks loaded fine into Pharo as Metacello configured packages and both had gotchas which required some experience in Smalltalk - unlike the Gofer and Metacello tools themselves.

What was distinctive in Aida was the need to make changes across many framework classes - and in Pharo Smalltalk, I can see no way to move new methods for base classes into my packages other than the *extensions mechanism.

The worst problem was an >>initialize method which started with super initialize and then failed to call a private method - the one mechanism that permits a subclass to override initialize properly ( I will submit my change as a fix.)

A serious problem was the lack of critical cleanup and reset methods ( I only needed to add one to Seaside for WAKom.)  I will submit these to the Aida team.

You will not want to try to prototype anything in Aida without using the process browser tool and without running a set of >>allInstances sanity-check mthods.

The proliferation of objects comes from inadequate cleanup - but in a Version 6 of Aida may reflect the reliance on loading packages into base images.  This is terrific for PITL but Smalltalk was always great for prototyping and that almost means maintaining a 'working' image - which is one way to spot objects that hang around.

In the early days of Seaside my rule was to discard any image in which Seaside had launched.  For anything other than prototyping, Aida would mean working from a close-to core base image.  That's just my take on what I saw after running two subclasses of SwazooSite in the same image, stopping, saving, quitting, launching ST.

And all bets are off until I have seen what a production image looks like - in the old days this was a matter of "stripping" images down - but we should now be in the age of building core images up.

I say that with a clear awareness of just how tiny servers can be in other alternative languages - such as Rebol - aside from any issues of code getting reused, code being understood and code being maintainable.

In the positive column: Aida has achieved a dialect for composing web pages which I think is on a par with Seaside.  But Rebol is also great at dialecting ... so dialecting is not enough.

In secure corporate environments where Curl shines, I remain concerned with the use of a pharo.st file at startup.  On the other side of that coin, the Aida tag method looks as if it should be reading from a resource file as adding a new tag should not always be a matter of changing framework level code.

At this time I have more of Curl running under Seaside but neither have the equivalent of 'halos' in Curl yet - so the jury is still out on a Smalltalk web framework for Curl markup.

Curl has great prospects in Asia, the subcontinent and Africa (most professional Curl developers are in India and Japan) wherever security is paramount.

My current work has moved from "eyes-only" document browsing* to "dark documents" on analogy with "dark matter": shedding light on a file directory or a DB table does not reveal them.  The key is to make "dark documents" run light in collaborative environments.  Both Smalltalk and Curl come with such excellent programmer facilities that they make a terrific match for prototyping a dark objects source and viewers.  And Curl has an exisiting inheritance mechanism near to Traits and no barrier to evolution away from classic OOP  (having been designed and implemented by MIT Lisp and Scheme experts at curl.com)

More to follow ...
* a early prototype for which there are links at logiquewerks.com and at aule-browser.com - both required the Curl runtime for the browser or the Curl REPL with scripted variants.

Pharo Curl

It took some effort again to get Curl markup running as an alternative to HTML+JavaScript on Seaside 3.0 on Pharo 1.1.1 Smalltalk.

The worst nuisance was Seaside using a method named text: for the equivalent of stream nextPutAll: or document print

This is because text is a common declarative identifier in Curl markup.  But it is only an annoyance and without examing available selectors at runtime or usinf perform: I can't see a workaround while leaving Seaside intact.

What was vexing was to still have to modifiy the WAAdmin class to defeat HTML-bias built into the framework.  And one or two other known quirks.

If only Seaside would embrace Traits on Pharo Smalltalk!  Traits would make it so clear that the choice of markup can be separated from the choice to use continuations, to use halos ...

Traits might also reduce the reliance on the Decorator pattern.  In a language with late binding, this leads to odd code, such as assigning a stream to an object whose class name and instance identifier clearly mean that it is not a stream ( but of course it is a decorator of a stream.)

Traits might reduce the reliance on the visitor pattern whcih I think reduces the understandability of code far more than double-dispatch itself because of the proliferation of visitor classes.  It is no longer necessary to ake a virtue of that necessity ( dare we now say, 'limitation' ?)

Many things are improved in Seaside 3.0 so that overall flipping from HTML markup to Curl goes well in the details - especially in a reduced need to subclass where closed tags happen to be identical across HTML and Curl.

It was amusing to me this time to add crlf so as to get better formatted Curl markup to inspect using the Curl source inspector - and spc to put spaces into the markup layout itself (Curl ignores whitespace the same an HTML client.)

The one concession was to use txt: to dump plain text - but super was not enough to preserve a Curl text: tag - for that I had to look at the runtime class so blocks go to text: and strings go to the canvas encoder for printing.

Curl 'attributes' (properties and options) are laid out the same as Seaside HtmlAttributes so anyone who can layout HTML for Seaside can layout Curl while remaining on 'the gentle slope' of the Curl language when used for declarative web content markup.

It still may be that Aida will be a better home for Curl poetry markup on a Pharo Smalltalk web server.