So here I am, happily hacking along at my first Iliad web application, when I get all fancy and want to set it up on a public server.

Heh ... a bit of fiddling required, since neither "my" Iliad nor "my" gst are out of the box anymore, but applying two patches is not too hard work.

Now I have everything ready: patched gst starts the REPL, gst-package builds OnlineTester.star, gst-load -viI ot.im OnlineTester ... throws an error, while starting Swazoo. Ah, yes, I think quickly, that port is already in use here. So I change, rinse and repeat ... and the error is still there. A FileError? When opening a socket. What?

So here we go again ... this time using native Smalltalk code to describe package contents in a DRY way:

Eval [
  PackageBuilder new
    name: 'MyPackage';
    namespace: 'MyNamespace';
    prereq: 'Package1';
    prereq: 'Package2';
    ...
    testsBelow: 'Tests' matching: '*.st';
    filein: 'File1.st';
    filein: 'File2.st';
    ...
    buildXml
]

In the previous part, I explained the basic concepts behind Iliad Applications and Widgets, through the simple counter example. This part will show how to use Magritte to automatically build views and editors with data validation.

Hi again,

it took me some time today with big support from Nicolas, to figure out how to using an own version of a session.

And before you run into the same mistake than me, I would like to decribe the really simple steps to use an own Session for your Iliad-Applications.

I made some errors in reasoning, which was my problem at the end. But here's how a session could be subclassed and used.

If you are used to having one class per file, package descriptions tend to get a bit unwieldy. Take a look at Iliad's Core/package.xml, as an example. What you see is a lot of typing, some of it, gasp, even repeated. Let's DRY this up a bit.