Edit Rename Changes History Upload Download Back to Top

SkillsBase Application Structure

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