Design & Architecture

This page should explain the overall design of the info-arena website and judge. Such a document is important because it offers a large view of the whole system and makes it easier to contribute. This is in no way to meant to be some sort of reference documentation, only a way to better understand how the code works.

Unfortunately this document is right now incomplete. Most of the coding in Coding Camp Chuckie was done cowboy-style, with little formal documentation. I hope that future architecture work on ia2 will take place on the wiki, as it is one of the best online collaboration systems.

If you like this project then go read the HackingTutorial and CodingStandards and join us. Happy coding

General sttuf

One of the most important design principles behind info-arena is simplicity. We try to do everything in the simplest possible way. We also try to avoid OOP unless absolutely necesarry (like when using 3rd party libs).

There are some other pages you might want to read before digging into the architecture.

• Our coding standards
• The logging system
• Directory structure
• Configuration files
• Url scheme

Model-View-Controller

Despite dropping OOP, the info-arena website is designed around the tried and true  Model-View-Controller(MVC) pattern.

We try to enforce strict code separation to have a clean design and at the same time keep thing as simple as possible.

Broadly speaking, "models" are things (usually class instances) that represent logical entities in an application. Models are thing like users, wiki pages or problems and are commonly closely couples with database tables. Right now we use php hashes to interact with the models in code and a bunch of global php function to interact with the database. The hashes are just what you get from functions like  mysql_fetch_assoc.

Views are chunks of code that are responsible for printing the actual html output of a web-page. A lot of applications use complicated templating systems, all we use is a bunch of .php files in the www/views/ directory.

Controllers represent the actual logic behind the web site, things like data manipulation and validation. Code in index.php parse the url and pass control to one of the controller functions in www/controllers/ directory.

For detailed information about how the model-view-controller pattern is used and code samples see ModelViewController.

Wiki-centric design

At the very heart of info-arena is a wiki system. The vast majority of content is in the new website will be little more than plain text. See InfoarenaWikiSystem for detailed documentation.

We use  Textile ( TextilePHP implementation) to format our text for fancier presentation in html. Inventing a new wiki syntax is pointless and textile is already  incredibly powerful.

We use a system of macros and templates to insert complex entities in the generated html, including tables and statistics.

Programming contests

The main function of info-arena is holding programming contests and a problem archive with a permanent live grader. In code programming contests are implemented using the following objects:

• Tasks represent the actual programming assignment, they are responsible mostly for giving scores to user submissions.
• Rounds represent problem sets, in code they are responsbile for deciding when tasks become visible, when user submissions are evaluated, etc.
• A rankings system could be used to combine submission scores into more complex ratings.

Actual long contests like Preoni are compossed of numerous individual rounds (which are in turn composed of individual tasks). All they need is a wiki page linking to the various rounds and a ranking that builds up the final score. The final scores can be displayed with a macro.

Judge daemon

Info-arena is not a pure web-application, it has a permanent daemon (background process) running at all times. We call it the Evaluation and Monitoring and Agent: EMA. Right now this daemon is used only to judge user submission but we plan to do more with it (see #68).

See the main judge page?.

Database stuff

Right now all database interactions are done through global functions in common/db. Data is manipulated as simple php hashes and there is no fancy system of object-relational mappings or caching.

FIXME: write more about the database?