MichaelErichsen
commented
6 years ago The mock-up contains a functioning separation between data access, business logic, communication logic, and user interface, which is already implementing both running client/server and single-machine, implementing the thoughts of Nils, and which have been tested by him. It will of course need refinement along the way.
I will build a template for Laney and rewrite the documentation, so you can write your part to be plugged into the skeleton. If I am lucky it can be done in about a week's time.
RobinLamacraft
Robin:
here would a need to implement an agreed set of APIs to the Substitution area and they would used in the skeleton a crude placeholder module was included. That would be replaced by the full one once it had been reasonably test in its sandpit. The Substitutions area would rely on another agreed set of APIs, to built by Michael to prove the storage of the template elementes and the database retrieval of values that Laney's code wanted to use, but at the start that can be ghosted in a sandpit.
THE PROPOSED TASK FOR LANEY (Overview - more detail later if agreed)
In TMG there are namestyle templates and sentences templates where a markup means to substitute that mark with a user data derived text string. The same concept applies in HRE with a more complete set of operators and larger environment from which retrieved values may be sourced. In HRE, the use of this mechanism is extended to error and warning messages, filter definitions, sorting definitions, memos with embedded Citations, selection of columns for tabular output and later in other types of report generation.
In HRE jargon this is the Substitutions area. The definition of and the evaluation of substitution templates becomes the core that provides the flexibility for the user to configure HRE to match their workflow needs. The substitutions area directly involves about 14 database tables and some auxiliary tables for each use. case.
The task would involve the GUI to create/edit/store/evaluate the template an the code required to manage the associated database tables (via APTs defined with Michael). In the process Business Rules level would need to provide validity checks for definition editing and execution.
Much of the preloading of the lookup tables in the database and the ability to store user data for any manual or importing from TMG will rely their being agreed structures and methods from the substitution area.
INTERACTIONS with the team MICHAEL (1) to continue with the structure of skeleton including GUI and other BR modules as required
(2) with LANEY jointly to define APIs for evaluation of templates for each type of use of Substitutions
(3) with Laney jointly defined APIs for the storage and retrieval of data related to definition and use of Substitutions.
LANEY (1) to build the GUI for defining/editing/managing/validating any use of Substitutions
(2) code to evaluate substitution templates and return the content to the requester
ROBIN (1) to provide additional documentation on the internals of Substitutions and their use cases.
(2) This documentation is currently being drafted to augment what has been already placed on GitHub
(3) To liaise with MICHAEL and LANEY to ensure the intention of the data model is achieved. It is quite likely that minor changes in the field set of some tables may need adjustment.
INTEGRATION
When LANEY's code has be tested in isolation and seems robust enough, then it can be integrated into the HRE skeleton.
There are other important tasks, (a). dates and time intervals (Java), (b). field and record validation rules (Jython) that can start in the same way if others wish to be come involved.