Subsystem Architecture

This page describe which subsystems are there in Agilo and how a subsystem should be structured.

Current Subsystems

  • Core/Base
    • ORM (PersistentObject)
    • ...
    • Basic Chart Infrastructure (+ Caching)
  • Ticket/Links
  • CSV Import
  • Scrum
    • Team (+ Calendar, Metrics)
    • Sprint (+Contingent)
    • Backlog (+ Burndown)

I tried to break up agilo.scrum into pieces but this was not possible because all the models depend too much on each other.

Subsystem Structure

A subsystem should be as self-contained as possible (it should include also the necessary templates and resource files). Subsystems may depend on each other.

A typical subsystem contains the following items:

  • api - contains interface declarations and exception definitions, everything which is really considered 'public'
  • admin - contains the admin interface (if there is one), if there are several pages, this can be actually a package itself but all necessary pages should imported as symbols in admin/init.py then.
  • functional_tests - functional tests for this module
  • htdocs - contains static resources which usually go in subdirectories like 'css', 'images' and 'js'.
  • model - contains the python classes which make the db accessible in an object-oriented manner (db abstraction)
  • templates - Templates needed for the (web_)ui
  • tests - unit tests
  • web_ui - contains all code necessary to display a web page (HTML). Alternative output implementations go in a module named json_ui.

If either htdocs or templates are present, the subsystem must contain an ITemplateProvider which should be named '...Provider'. Other Python modules should live in sensibly named files besides the items which are mentioned above. If a package contains multiple implementations of some informal interface (e.g. different performers for CVS import/export/modify), they should be grouped in one subdirectory.

The __init.py in a subsystem should not contain much code, mostly imports or maybe constants (though these could go into api). The __init file may have imports for all Components in this package so we can reduce the number of items in setup.py.

I wrote some custom test loading utilities (based on TaZ' work) to load all tests within a given directory (including infrastructure to do that recursively). Look in the agilo.search package for usage examples.

Database Schema

All subsystems in Agilo (Open Source) have centralized upgrade scripts (and therefore only one db revision number). The idea there is that they don't depend on other packages - even if this is not true atm.

agilo.ticket

The agilo.ticket package is a bit different because we try to stick to trac's class layout as close as possible so it is easier for developers to find the right things. For many issues in this package you have to check both trac and Agilo because we extend many things in a very subtle way.

Last modified 10 years ago Last modified on 01/30/2009 02:23:56 PM

1.3.15 © 2008-2016 Agilo Software all rights reserved (this page was served in: 0.16167 sec.)