New Fun Design

[This is really more of a notes page than a proper design doc at this point. An announcement will be sent to gcd-tech when this page is ready for public review. Although feel free to comment before then.]

Python Code

Models

 package: apps.gcd.models
 modules: One per table
 classes: One per table/module

Most of the structure of the model classes is determined by the database structure. The tables and columns will be renamed to conform to PEP-8 naming standards and avoid most abbreviations. Abbreviations that are retained will be used consistently.

Models may support properties built from multiple columns to ease migration to the new schema and/or reduce the calculations necessary in the UI layer. Models may not directly emit UI markup.

Views

The views modules should only include functions called directly as views, plus code that is tightly coupled with those functions (for instance, functions that implement one action but are split up for organzational or length purposes rather than to add abstraction layers). Code that implements a concept separate from direct view access should go in a support module.

 package: apps.gcd.views
 modules:
   apps.gcd.details: Detailed data on the primary database objects.
   apps.gcd.search: Integration with Solr.
 classes:
   none, views are function-based and classes should go in support.

Support

These modules implement abstractions or concepts on which the views or other code in the system rely, but which are not backed directly by the database and therefore are not models.

 package: apps.gcd.support
 modules:
   apps.gcd.covers: Abstraction for the ever-changing location of covers scans.