Active Agenda | The Technology (original) (raw)
This will serve as the "root" page for all technical topics. It should link directly or indirectly to every technical article in the wiki.
The current version of Active Agenda is built for the Linux - Apache - MySQL - PHP platform (the "LAMP" stack), but thanks to the XML-based meta structure of its modules, it can be ported to support other platforms.
Active Agenda is intended to be installed on a dedicated server
or a virtual dedicated server, but not on a shared hosting account.
Current installations have all involved placing the MySQL database on the same box as the web server, but separating them shouldn't involve too many problems.
Installing Active Agenda
We have made many advances since the early releases of Active Agenda. We have reduced our dependency to the PHP programming language. All other layers are much more flexible.
If your server isn't already running the necessary server software, you might wish to look into XAMPP, an integrated installer that covers all the software needed to install and run Active Agenda. This is especially helpful for the Windows platform (XAMPP), which doesn't have easy package managers like most Linux distributions. You must have the server software running before you can successfully install Active Agenda.
Architecture
Active Agenda is, technically speaking, a large relational database with a web interface that allows users to add and modify data.
Each table in the database is represented by a "module", which serves as the metaphor for all meta-data that is associated with that table.
This meta-data is defined in an XML file for each module, consolidating data table structure together with relationships with other tables, user interface "screens" and form fields, as well as module-specific documentation.
Rather than turning the XML meta-data into a running application "on the fly", Active Agenda uses a "generator" that translates the XML structure into generated files? that contain the module-specific logic.
Therefore we speak of "generating time" and "run time" as separate states? in which the code might be executed.
The generator will typically hard-code data from the XML definitions into the generated files, which will then remain static unless the XML definition changes.
Functionality which is not module-specific is coded directly into the framework application, and is not represented in any XML file. This includes the user login functionality, user permissions, and the logic that handles the basic page display.
Development Process
Active Agenda is a "highly iterative, rapidly customizable, communication development framework." Active Agenda is a practical implementation of Domain Driven Design (DDD).
An important benefit of the XML module definition approach is that it enabled a "power user" (but non-programmer) to define what fields are displayed on what screen, how they are labeled and how the data in one module relates to another.
Under a traditional programming model, the domain expert would create specs or change requests using less structured formats (such as free form text or pictures), to be interpreted and implemented by a programmer. After the programmer is done, the domain person would check the new functionality, and if corrections or changes are needed (because of failures in the human communication), a new change request is started.
Frequently, seeing the new functionality in action would give the domain person new ideas for improvements, or lead to the realization that the user interface is flawed from a user interaction perspective, which would then require another change request.
Active Agenda's XML spec development process changes all that. We refer to it as "spec2app". It means that the user expert can implement new modules, and do many changes, fixes and updates to the user interface and data structure without having to involve (and wait for) a programmer before seeing them in action. Precise definitions in a highly structured format also means that the risk of human misunderstandings in communicating and interpreting these specs is reduced. The XML specs also double as reference documentation.
Customizing Active Agenda
Modules
In Active Agenda, a module is really a table within the database. Modules can be easily added and/or customized using XML and simple syntax. The XML module definitions generate the tables, table relationships, user interface, charts, and a variety of built in functionalities (e.g. blank forms for manual data collection).
Module Fields
Module fields are modified using simple XML module definition files. Module table fields are added or customized within the element. Any field stipulated within the section can be included within the module's record list (), made searchable within the , displayed on it's , made available for data entry on one or more and used to make .
Table Relationships
Active Agenda's module structure is simple and straight forward. We use submodules to create one to many relationships between modules. Submodules can be limited to direct relationships between a module and submodules that are specific to the parent, or central submodules can be used to establish one-to-many relationship between one submodules and many parents. We use association modules for many-to-many relationships.
Using AddOn Files
AddOn files provide a way to extend an XML Module Definition of a "host" module without modifying the original module definition file. An AddOn file is in itself an XML file. The purpose of this functionality is to enable easier distribution of additions to the standard module definitions.
Optional AddOns
The AddOn capability has been extended to enable "optional" AddOns that may be useful to people based on similar industries (e.g. education), similar topics (e.g. injury reporting), or similar jurisdictions (e.g. California). The Optional files are located in the 'active_agenda/optional' subfolders (see image below). Optional folders must be stipulated within the config.php file located in the active_agenda folder.
Themes
You must create a theme before you can generate one! Active Agenda uses an XML theme configuration file to stipulate the colors and images to be used with a theme file (theme-config.xml). The theme configuration file is located in the active_agenda/web/themes folder. A great way to start a custom theme file is to copy a named theme folder (e.g. aa_theme) into the active_agenda/web/themes folder under a new name.
System Modules
System modules are tables used by the system during module generation. These modules are not exposed to users and run in the background. You should consider these modules "off limits" and avoid temptations to modify them. Modifying system modules will negatively impact functionality.
Calculated Severity Cache
Consistency Condition States
Charts
Dashboard Charts
Dashboard Chart Conditions
Code Type Dependencies
The Code Type Dependencies module is automatically populated during module generation. The module captures and lists all of the modules that "depend on" each code type. If a code type appears in a module, it is listed in the Code Type Dependencies list.
The only field you can modify in the Code Type Dependencies module is the Master Article field. This field allows you to assign a master support article to each code type dependency. These associations make it possible to generate a Tiki Wiki table formatted report. The report allows you to insert the Tiki Wiki table syntax into the respective support articles. The Tiki formatted tables include the: Code Type ID; Code Title; and which module(s) use which codes types.
Record Description Cache
The Record Description Cache is a system module (moduleID: rdc) that contains auto-calculated data which is used for describing any record in the database when referenced from a global module or central sub-module. Each module has its own definition of the record description, but they generally consist of a combination of various important fields in the module.