Pangloss Technical Specification

Author: Steve Purkis <spurkis@quiup.com>
Date: 01/04/2003
$Revision: 1.3 $, $Author: spurkis $
$Date: 2003/04/11 17:13:33 $

Table of Contents

1. Project Overview
2. System Architecture
3. Overview of Classes
4. Application Logic
5. Design Decisions

1 Project Overview

This document outlines the technical requirements of Pangloss, a multilingual terminology management system.

1.1 Assumptions

1.2 Notes

2 System Architecture

An overview of the system architecture of Pangloss is shown in Figure 1.

Fig. 1: Pangloss Architecture
Pangloss Architecture This includes: Though Pangloss will be developed in Apache/mod_perl 1, support for Apache 2.x / mod_perl 2 is desirable.

Compatibility with MKDoc users will be supported through the MKDoc HTTP/mod_perl authentication module.

Pangloss will be developed and tested under Linux and Mac OS X using CVS for version control. The target platform is Linux. Support for other platforms including Win32 and other flavours of Unix is desirable but not required. Localization of Pangloss (ie: support for multi-lingual templates, errors, and messages) is also desirable but not required.

3 Overview of Classes

Pangloss Classes
Fig. 2: Pangloss Classes
Pangloss will be developed in the style of a Model-View-Controller (MVC) application. Figure 2 outlines parts of the model and the view, the controller is detailed in section 4.

One of the main goals behind this approach is to build a system that has a high number of reusable parts, and who's functionality is easy to change.

The Application class will be the main entry point to the system, handling most if not all of the controller's requests. It will pass Views back up to the controller for use in templates.

Object persistency will initially be achieved through use of Pixie to speed up development time. If necessary, Class::DBI may be used in the future to store data using a well-defined database schema.

... what else have I missed? ...

4 Application Logic

This section details the controller of Pangloss - it is effectively a high-level overview of Pangloss' logic flow. It's based on the idea of Pipeline Segments (so hopefully there will be a 1:1 mapping), and assumes it is running in OpenFrame (ie: there is an OpenFrame::Request in the store, etc..). Each segment will be minimalistic in that most of the work will be done by the model, as outlined in section 3. In saying that, it is worth noting that templates will be chosen by the controller so that the model does not have to concern itself with presentation logic.

For each request, Pangloss will execute the following:

  1. Loaders
      Load Session()
      • Decline User Exists
        Load User( remote user )
      Load Selected Filters( ... )
      Load Selected User( username )
      Load Selected Concept( concept name)
      Load Selected Term( term name )
      Load Selected Language( language name )
      Load Text Document( text | blob )
      Load Html Document( URI )

  2. Login
      Decline No User
      Login( username, password ) probably not needed?

  3. Generate Glossary
    • Decline No Filters
      Generate Glossary( filters )
    • Decline No Document
      Generate Glossary From Text( text doc )
      Generate Glossary From Html( html doc )

  4. Administer Terms
      Decline No Term
      • Decline Not Translator
        Decline Term Exists
        Add Term( concept, language, new term, notes )
      • Decline Not Proofreader
        Modify Term Status( term, new status, notes )
      • Decline Not Administrator
        Modify Term( term, ... )
        Delete Term( term )

  5. Administer Users
      Decline No User Selected
      • Decline Not Administrator
        Decline Term Exists
        Add User( name, type )
      Modify User( user, ... )
      Delete User( user ) does not *really* delete user

  6. Administer Concepts
      Decline No Concept
      • Decline Not Administrator
        Decline Concept Exists
        Add New Concept( name, description )
      Modify Concept( concept, ... )
      Delete Concept( concept ) deletes associated terms too

  7. Administer Languages
      Decline No Language
      Add New Language( name, iso code )
      Modify User( language, ... )
      Delete Language( language ) deletes associated concepts + terms too

  8. Load Filter Options()

  9. Process Template
      Decline No Template
      Add Messages To Template()
      Add Errors To Template()
      Load Template()

5 Design Decisions

The following design decisions have been made to give the prject consistency:
  1. All classes will be tested using Test::More.
  2. Errors in the model will be handled using Exceptions from Error.
  3. Accessor methods will return the object so that they may be cascaded.