Protocol 07.02.2008
We discussed some central points of the implementation at the user group meeting on 2008-02-02. The following decision were agreed on:
Decisions
License
The license of the project will be GPL in version 3 (exclusively, not automatically higher).
Module definition
The module design document will be rewritten, to reflect the following issues:
-
There will be only 1 file returning some arbitrary structure, which needs to be defined in further detail and contains all the already mentioned information.
The main reason for this decision is, that we may need further information at a later stage, and do not want to add a requirement for further files in the module root with names that might conflict with existing files in the module. This also reduces the stat() calls to the file system on module initialization.
Directory naming scheme
The root node contains the following directories:
-
website/
-
releases/
-
doc/
-
trunk/
The trunk/ directory contains the following names:
-
src/
-
doc/
-
tests/
Inside the src/ directory no abbreviations are used for the directories, for now we now about the following directories, new ones need to follow the same naming scheme:
-
classes/
The core classes
-
libraries/
External libraries which are used by us
-
modules/
The core modules
Logo
We decided on the logo with the current name "arbit_eye_2.svg". Later this will be available as "arbit_logo.svg" in the doc folder.
Configuration
We decided again to use configuration files, with the basic structure as defined in trunk at the current revision.
We will not use XML, because this is to hard and complex to modify for an average user. As the editing of the configuration is the entry point for each user this hurdle is too high for arbit.
We will not YAML, because the format just sucks and is nearly as complex to edit as XML for the average user.
MVC
We shortly discussed the type of MVC controller and view structure we want to use. This is a rough description of the discussion result, for the example of a requested dashboard (the overview page with all projects).
-
After processing the request input, the dashboard controller is called, to fetch the required data and send it to the view.
-
The dashboard controller fetches a list of projects from the business model, which itself requests the data from the facade. For each project a subcontroller is called to fetch the required dashboard information.
-
The subcontroller creates a view structure with containers for the required data, which in the case of the dashboard will be something like:
-
bool module_status
-
string module_short_description
-
float module_quality_factor
Now a signal, named something like 'project_dashboard_status' is created and sent, which includes the defined view structure and may be caught by subcontrollers, residing in other modules or the core. These subcontrollers may append data (of the correct type) to the fields in the view structure. The signal contains the project that data is to be gathered about.
In the case above most plugins will have a slot for this signal and may append data to the given slots in the view structure. The view structure will then be sent, together with the request structure, to the view manager, which then will select a view for the data, and display it.
-
This example basically shows two things:
-
Data may be fetched directly from the module by controller, if there is an easy API for this case.
-
Complex data structures, which need to build in the controller and may be useful to be extended by some module some day are handled by a signal slot implementation with view structure references as parameter, like describes above.