This page covers development issues and notes. See the specific pages for:
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.
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
- The v is a simple integer version number. e.g. 1, 2 or 5656
- The iii is an increment that indicates the attempt number for achieving the version. So, when work starts on version 2, the first increment would be 001, so the whole version string would be "2 001", the next version name for work on getting version 2 going would be "2 002" and so on.
- The .nnxx is an optional suffix if you are publishing changes to a bundle you don't own. So, if I changed something that was currently being managed by someone else, I might publish it as 2 034.bb01 to indicate that this is my version branching from 2 034. The owner can see my work and can then merge it into the main branch as appropriate.
- Squid bug 897 means that exported HR-XML files have a blank line at the top, which makes them invalid. The work-around is to edit the file and delete the blank line and also add any missing > characters at the end (which it seems get dropped because squid does not increment the value of the contentLength HTTP header to take account of the crlf added to the front) :-/
- Interface with LDAP to translate login IDs to member numbers. See the library written by Thomas Gagne.
- Interface to OpenPGP?
This is just to note down the essential tasks that are to be supported by the SkillsBase.
- Login - Authentication should be a matter of checking against LDAP
- Search - Find members on the basis of skills
- Edit Skills Tree - add skills to the skills tree & move existing skills around
- Add an engagement - member captures details of an engagement
- Map engagement to skill - For an engagement, find a skill & link the two
- User preferences - members should be able to hide their engagements from searches (all or nothing - at least for now)
- Commendations - can come later, but will involve a member locating the engagement of another member, and commending them for skill(s) associated with that engagement.
- Client commendations - much later (how do we verify clients?)
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.
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:
- Load the "OS SkillsBase Development" bundle from the OpenSkills common StORE repository
- Have a look at the comment on the "OS SkillsBase WebUI" package, and (taken from the comment):
- Start the SkillsBase service (and implicitly the Hyper HTTP server)
- Put a breakpoint in OSSBWebService>>handle:
- Point a browser at http://:10080
- Trace through the code as you read the following ...
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.
- An OSSBLoginPage is the user got the username/password wrong.
- An OSSBHomePage if the user pressed cancel.
- An OSSBMemberHomePage if the user got the username/password right.
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.