Edit Rename Changes History Upload Download Back to Top

OpenSkills SkillsBase Development

This page covers development issues and notes. See the specific pages for:

Development Environment

The SkillsBase is primarily written in Smalltalk, and all code is held in the Smalltalk version control system Store, so firstly, etablish a Smalltalk Development Environment with a working directory for the SkillsBase.

Start a clean VisualWorks image (should be something like "./01-visual" if you followed the instuctions above).

Loading up the code

All versions of the system are available from the OpenSkills common Store repository, but please do not load the bundle directly from there. Instead, replicate the bundle to your local Store repository and load from that.

So, load the "OS SkillsBase Development" bundle into the clean VisualWorks image from your local Store repository.

... start coding.

Version Numbering

When publishing changes to the SkillsBase, always publish the top most development bundle. This will keep all the work contained in your version together. The alternative to to publish only the component bundles and packages that you have changed - don't do this.

Version names must take the form v iii.nnxx


To Do

Use cases

This is just to note down the essential tasks that are to be supported by the SkillsBase.

Implementation Notes

Class Names

Class names are prefixed with OSSB (for OpenSkills SkillsBase) because not all Smalltalk implementations support namespaces yet, and the system should be portable, particularly, to the two open souce Smalltalks: Squeak and GNU Smalltalk.

Getting Started

The SkillsBase system will be first deployed with an HTML/CSS UI delivered to client browsers via the Hyper HTTP server.

To get a handle on the implementation of the system:

HTTPTask and Session Data

When the OSSBWebService receives an HTTPRequest, it creates an OSSBHTTPTask to contain the request, the session data and the response. When created, the task object knows only the request. From this it creates the stating session data in an instance of OSSBSessionData.

At any instant, the task object represents the current state of the process of formulating a response to the request.

The task object is passed to the OSSBTarget class which handles the formulation of a response. When the target object has finsihed, the resulting state of the response is held in the task object. The OSSBWebService sends >>finalResponse to the task which responds by updating the response headers with the session data, and returning the complete response which is then returned to the client browser.

Targets: Pages & Actions

Every HTTP request, wrapped in an OSSBTask, will be directed at a target class on the basis of the HTTPD Identifier in the request header. An instance of the target class is be created to handle the request. The target class may either be a subclass of OSSBPage or OSSBAction.

A Page target will always respond with a given page. For example the OSSBHomePage is a target that simply responds by displaying the home page.

An Action target may respond with any one of a number of pages. For example, the OSSBLoginAction will respond with one of:

Any target object may modify the session data in the task object.

CSS & Page Layout

All of the layout and appearance issues that can be expressed in CSS should be expressed in CSS. This is in order to minimize the bulk and complexity of the HTML served up by the application.

All of the CSS needed by the system will be served up to the client in a single "page". This will reduce the number of round-trips between the client browser and the server. When Squid is employed, the server will be pestered only once for the CSS, and will be able to spend all of it's resources serving up the high-value HTML page content.

Each page of the application UI will be defined in terms of a number of (possibly nested) rectangular regions. These regions will be expressed using HTML DIV elements. This, plus CSS, gives us very precise control over where each rectangular region appears either relative to the page, the browser window or a parent (containing) element (probably another DIV). It also lets us reuse div elements across many pages.

Each region will be represented by a class called OSSBxxxDiv. The class will have a class-side >>writeCSSTo: method which will write all of the style elements that may be used in the HTML produced by instances of that class.

All pages refer to a style page called 'style.css'. When the server receives a request for this page, it visits all subclasses of OSSBHTMLElement and if they return true to >>hasCSS gets them to write their CSS to a stream using >>writeCSSTo:. In the production system the result of this exercise will be cached - if only in Squid.

Dreamweaver also uses the rectangular-regions technique. It calls the regions "layers". It should be possible, therefore, to get the look of the page together in something like Dreamweaver, and simply move the DIV and CSS code from the files saved by Dreamweaver to the classes in the system.

Edit Rename Changes History Upload Download Back to Top