Visa denna sidaEditera denna sidaLås denna sidaLänkar till denna sidaBilagor till denna sidaHistorik för denna sidaSwikins toppSenaste ändringarSök i SwikinHjälpguide

An introduction


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:
  1. KomHttpServer, a web server written in Squeak offering total independence and integration.
  2. Seaside, a novel continuation based web framework. Seaside is probably the best of its kind today and has inspired similar projects in other languages.
  3. 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:


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

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:

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.