[software] Rapport2 (was Re: OffstageArts and CiviCRM)

[Bob F]

> As far as modularity, my long-term vision for Rapport is to be able to
> integrate different chunks of features that people can enable or  
> disable
> via config

Drupal has implemented this kind of thing nicely.

> It also has a pretty thorough custom field implementation for
> contacts (not yet coded but in the database ;), which shold handle  
> a lot
> of custom workflow.

I implemented custom fields simply by adding them to the database  
schema:

ALTER TABLE persons add field (custom_myfield int);  (or whatever the  
syntax is).

A little bit more code in the main app then adds the custom fields to  
the query system.  And changing the GUI layouts (see below) allows  
the field to display as needed.  This approach allows for  
customization with the least amount of code.

Similarly, tabs are added by creating new tables in the schema and a  
bit of extra code.

> I'm _not_ too interested in a plugin API, as it seems like big apps  
> with a
> plugin API end up becoming a mess for the sake of plugins.

Any class in OffstageArts can be designated as customizable in the  
core code base, and then overridden by a replacement class coming  
from the "sitecode.jar", which is the bundle of customizations loaded  
into the database.  Designating a class as customizable is very easy,  
it just involves changing the way the class is instantiated  
slightly.  (NOTE: only chosen classes can be overridden.  This allows  
the system designer to maintain control over which classes are and  
are not OK to override, i.e. it maintains a strict adherence to  
extending only documented parts of the system).

Adding a field to the on-screen layout simply involves overriding the  
appropriate GUI layout classes.  I've included a screenshot here of  
the same data entry screen of the very same version of OffstageArts,  
but running on two different databases.  Note the differences in both  
fields and tabs, and the fact that the end user doesn't really know  
(or care) which fields and tabs are customized and which are part of  
the main codebase:

http://offstagearts.org/tmp/devel1.tiff
http://offstagearts.org/tmp/devel2.tiff

Customizations are also used, for example, to calculate school  
tuition.  Tuition policies are complex, and they vary by  
organization.  School tuition is implemented by subclassing a tuition  
base class, and then implementing the correct computation.  When you  
set up a term in the school, you tell it which Java class to use to  
calculate tuition (see the "Tuition Plans" column below):

http://offstagearts.org/tmp/tuitionPlans.tiff

I hope this gives some sense of the kinds of fine-grained  
customizations that are possible.  This is all very light-weight, I  
have not had to build any plug-in interfaces.  Potential  
customizations are limitless, subject only to good design in the core  
code base as to which classes can and cannot be overridden.

> The
> trick, then, is just managing database changes.

I've done two things:

1. The main database is versioned.  When the system connects, it auto- 
upgrades (with confirmation) to the latest version of the DB schema  
if required.  The application "knows" how to upgrade from any version  
of the schema to any other.  It even knows how to build a schema from  
a blank database, which makes setting up a new instance of the system  
pretty easy.  Here's an example of what happens when OA decides it  
needs to upgrade (sorry, the UI here sucks, but it has been  
functional and stable at managing multiple databases with zero effort  
as I change the schema rapidly as the system develops).

http://offstagearts.org/tmp/resources.tiff

2. I allow consultants to extend the database schema by adding  
additional tables and columns.  There should probably be a convention  
that customized tables and columns are prefixed by something ("sc_")  
so that the system can tell them apart from core tables and columns.

In general, the core and the customized database schema portions  
don't interact much; at least I haven't had any problems so far where  
a core database upgrade breaks a customized portion of the schema.

-- Bob