CompInaBox is a growing suite of tools for organizers of ballroom dance competitions and for the people who attend said competitions. CompInaBox has both on-line and off-line components. The on-line components are written in PHP and use a PostGreSQL Database to store their data. The off-line components use Java.
For the sake of documentation the source files have been tagged as belonging to different packages and subpackages. These divisions are rather artifical. If you have a suggested re-organization, please me know.
Classes supporting the access control infrastructure/
Server-side executable command-line scripts, used by a site administrator to generate exports or via cron to rebuild cached files.
The CompInaBox top-level package holds items that are used by practically every other element in the CompInaBox project. Ideally their would have been two top level packages: CompInaBox and Tests. However, the documentation tool only allows for one level of sub-packages below the top level packages and the name space got too clutters so most of the subpackages were elevated to top-level status.
This is an error package and hold files and classes that have not been assigned a real package/subpackage yet. If you're interested in helping write documentation, this is a great place to start!
This package holds files that are generally used for configuration details -- lists of constants or lists of other files to include. Some of the files are "stock" versions useful if you need to start from a clean slate.
The database abstraction layer. A base class DB that is the actual abstraction layer and then per-module APIs to hide SQL from the developer for commonly used queries with specific result formats.
Tools to produced printed lists, (X)HTML or LaTeX. The UIBASE hierarchy is one of the major work-horses of the CompInaBox project.
The CIB solution to the so-called "Object-Relational Impedience Mismatch". The SlidingDoors modules makes the most use of this, but more should over time. Basic entities are subclassed from StoredObject that allow them to interact transparently with the database while presenting a normal OOP interfacce to the developer.
Unit and acceptence tests are placed here. The test harness is currently extremely sparse, but test coverage is increasing. The lead developer is followinng TDD so all new features should have full test coverage.
A generic catch all for helper routines and classes.
All scripts reachable via the web browser, including "interstitual" pages that only processs data and then redirect.
Documentation generated on Tue, 25 Apr 2006 12:58:13 -0400 by phpDocumentor 1.3.0RC3