An introduction

Technology

Gjallar is written in Smalltalk using the open source implementation called Squeak. Squeak is a modern, open source, highly portable, fast and full-featured implementation of the powerful Smalltalk programming language and environment. When Smalltalk was created more than 35 years ago it defined the term object orientation and is the first language in which everything is built from objects. Smalltalk is deeply inspired by ideas from especially Simula, Sketchpad and Lisp and even today Smalltalk sets the bar for object oriented dynamically strongly typed interactive languages and environments.

The three most important addon components used in Gjallar are:

KomHttpServer, a web server written in Squeak offering total independence and integration.
Seaside, a novel continuation based web framework. Seaside is probably the best of its kind today and has inspired similar projects in other languages.
Magma, an advanced object database fully written and integrated in Squeak.

All these components and Squeak itself are open source with a very helpful and friendly development community that is steadily growing.
The above choices in combination with Squeak give us a very nice list of features:

Very mature and robust platform. Squeak is a very mature platform used for highly demanding projects. The virtual machine is simple but efficient and the libraries have been maturing for over 25 years (!) since it is a direct descendant of the original Smalltalk environment that was developed in the late 1970s. There are many Squeak systems that have been running for years without interruption.
Totally iterative development environment. Squeak is a fully reflective language meaning that there is no “compile time” mode – Squeak is always in “runtime”. It has full support for live object migration and uses an incremental compiler that never takes more than a fraction of a second to run. The effect is that you never have to stop the system you are developing – you simply run it at the same time as you are building it. Magma follows through on this principle all the way down to the database with live automatic schema migration and fully automatic storage and retrieval of complex objects. Very few environments come even close to this.
True crossplatform deployment without external dependencies. Squeak is totally cross platform and since we use a fully integrated webbserver and object database, both written in Squeak themselves, Gjallar will be totally self contained and crossplatform. The complete Gjallar system installer will probably weigh in at around 15-20Mb and does not require anything else to be installed. This is a very important aspect in order to support offline operation.
Fast development of highly sophisticated component based web user interfaces. Seaside is simply has unprecedented productivity and a very easy to use component model encouraging true component reuse. Through its advanced continuation based architecture it completely hides the complexity of the request/response model that otherwise plagues web development. No more hidden fields, url parameter embedding, strange things happening when the user hits the back button etc. etc.

Techniques

Several development techniques are used in the prototype in order to implement the system in a practical and efficient way. The transaction concept described in the design document is used throughout the model making offline operation and synchronization practical to implement. This concept is very much similar to the Command pattern described in “Design Patterns” (by the “Gang of Four”, see http://books.internet.com/books/0201633612).

Separation of domains is a basic OO principle and is followed strictly. All user interfaces are constructed as components that can be reused in other parts of the system and all forms are desribed in a meta model that is then rendered by “viewers” and “editors” making it very easy to change the user interface overall behaviour in a central place and more or less eliminates the need for hardcoded user interfaces.

The HTML generation is done using a HTML builder framework so no HTML is handwritten and the builder ensures that all emitted HTML is fully XHTML standards compliant. All visual appearance is governed separately using CSS1/2 as is the established professional way of constructing web interfaces today.

A range of other established practices in OO and Smalltalk programming are used like unit tests, composite patterns, equivalence and proper copy semantics, double dispatch and so on.

Spike solutions

Four areas were explored early on during development using spike solutions. These were:

Offline functionality with synchronization
Simple but “smart” user interface
Advanced workflow using dynamic forms and fields
Highly integrated directly editable context help

The implemented offline mechanism offers a way to produce so called “mirrors” which are partial copies of the Gjallar database which can be installed on another computer – like a laptop. The user then uses a full local installation of the Gjallar software to work with this “mirrored system” and can later on synchronize with the master Gjallar server.
The synchronization implementation uses serialized transaction objects of different types depending on transaction type. Synchronization today works in both directions but conflict detection and resolution is yet to be implemented, even though the hooks are all in place.
The user interface tries hard to be simple but smart. The base layout is the common left-hand-frame-with-navigation with a content area to the right which can scroll independently. This layout is done using CSS which means no frames were used that would affect the ability to handle the back button reliably.
Just a little bit of time was spent on colours and visual appearance in order to make it “nice” but lightweight. The generated XHTML is compact and all CSS is cached for fast page retrievals even on slower connections.
The different user interface components have extensive state tracking which means that while you are working on creating a case you can easily switch over to read an old case and then go back to writing the new case – you do not have to start all over. It also means that the back button is (or should be :)) fully supported in a logical way. We also use “tabs” to make forms short enough to fit on the screen and to logically hide and group information not needed at the moment.
The user interface can easily be further polished, the architecture in place makes this very easy to do afterwards because all visual appearance is centrally defined.

The design document describes a full workflow model using a graph of stages interconnected with transitions. While cases move from stage to stage the user should be able to “add” extra forms to the case. These forms are defined per process by the process administrator.

No forms are hardcoded – not even the basic form for creating or modifying the base information in the cases. Forms can be defined globally and imported (linked) into processes or copied from existing global template forms or defined from scratch per process. Even complete processes can be prepared as template processes and copied which means it is easy as a Gjallar administrator to create new processes with a common set of settings and form definitions.

In all user interfaces tooltips (floating one line descriptions of functions and fields) are enabled. If the user wants to all major objects (forms, fields, stages, links, processes, roles, users and more) in the system can be “wiki enabled”. This means that a wiki page is interwoven with the user interface and can be expanded in place by simply clicking on a small icon showing its presence.
Not only does this offer context help directly in the user interface but it also makes it possible for the user to click the “edit” link and modify the help page immediately and directly. This should eliminate any use of a separate help document and above all make it possible to document the actual process itself directly in the tool describing what the separate stages are and what each field should contain.

Source code management

All source is managed using Monticello – a modern easy to use but advanced source code management tool offer automatic and intelligent “Smalltalk aware“ 3-way merge and full history tracking. The coding style follows general Smalltalk principles with in general very short methods and fine grained classes.