This chapter is for developers which wish to contribute to Codestriker, and want a quick birds-eye view as to how the code is structured. The Codestriker modules are broken into the following sub-modules, which are located in lib/Codestriker:
Every action or gesture that can be performed on the Codestriker UI has an associated module for handling that action. The name of the module indicates what action it is handling.
Support for updating bug tracking systems when topics are created or their state is changed against specific bug reports. Currently, only Bugzilla is supported, but the API can support other bug-tracking systems.
A thin wrapper over the DBI interface, to create/remove database connections. Each database also has an associated module, to cater for subtle differences between database systems. Currently, there is support for MySQL, PostgreSQL, ODBC (SQL Server) and Oracle.
These modules are responsible for parsing the input text when topics are created. Currently, CVS unidiffs, PATCH unidiffs and Subversion diff files are supported. The API for these parsers is simply to accept input text, and to return an array of delta objects, which describe source code changes made to a specific file on specific lines. These delta objects are then used for rendering a topic, so that they are agnostic to which source control system they originated from.
This contains initial HTTP request processing, and support for generating an HTTP response, including the handling of cookies and compressed streams. This sub-module also contains the all-important Render.pm module, which is the work-horse for generating the complex HTML from the topic deltas.
This contains the persistent objects of the system, and the associated database operations on them. These objects include Topics, Comments, Files and Deltas. The Action classes eventually call these model objects when the persistent state of the system needs to be queried or modified.
A number of objects implement the Repository API, which is used throughout the system. Repositories currently supported include a local CVS repository, a remote CVS repository whose data is accessed by HTTP or the pserver protocol, and Subversion. Future repositories can be easily added to this framework. The methods in the repository API include a way of retrieving the entire contents of a specified file and revision (which is used in the ViewFile action module), and the generation of a revision file log URL.
This package contains a number of objects which are notified whenever a topic is changed, via a listener interface. Functionality such as email notification, Bugzilla integration, topic history recording are implemented here as topic listeners.
In addition to the above modules, the following directories are of interest:
This contains the all-important install.pl script, which is used for initialising the system, and for performing upgrades. This isn't the most pretty script in the world, partly for all of the old data-migration it has to do from old versions to the current version. This directory also contains SubmitCodeReview.pl which is a way of generating code reviews from the command line.
This contains the codestriker.pl CGI script. It reads the "action" parameter from the URL, and delegates the handling of the request to the appropriate action object.
This contains the codestriker.css file.
Almost all of the HTML generated by Codestriker (apart from the actual code rendering) can be customised by the templates within this directory. Each Action object typically has an associated template, where the view can be easily customized. There is also a header and footer template, which is included in every page, for site customization.
This directory contains the source for the Codestriker guide written in docbook, contained in the codestriker.sgml, with the Makefile for building the various forms of the documentation.