Data Objects - kwantu/platformconfiguration GitHub Wiki

Introduction

NOTE! An indicator; an SDO; a DO; a data object and a Set Id all refer to the same thing: a Data object.

Data objects are a way of defining (planning or monitoring) data in a standardised and re-usable way. DOs differ from other approaches to developing data standards in four key ways:

Difference	Explanation
Interoperable	DOs are defined using a domain specific language, which ensures that data for different types of DOs are defined in the same way. This means that different DOs related to different types of M&E or planning data will be defined in the same way.
Rich business context	The context of the data is critical to understand the quality of the data and it’s relationships with other data. DOs are designed to understand the full context related to the data, making it ‘self-aware’.
Standard data envelope	Each SDO includes a standard data envelope. This provides metadata to assist with exception and status reporting.
Offline first architecture	DOs store data in JSON files, which can be synchronised between a client device and a server. This approach enables data to be collected offline and synchronised as and when Internet is available

The data object (DO) paradigm is analogous to the metadata of a table in an RDBMS. The DO "definition meta data" is stored in a "configuration" file. The DO metadata instance files are in turn stored in the database along with their actual data. This is analogous to a data-model and its data inside of an RDBMS. The DO is defined by metadata in a "configuration file". Unlike a data-model in a RDBMS, the DO is not relational, it is hierarchical. The "DO configuration files" themselves are hierarchical too. Developing apps on the Kwantu platform involves editing "configuration files". Configuration files "tranformed" into the various app files used in the execution of the app.

The picture below illustrates a logical hierarchy of three layers of subordinate "nodes" to the apex "node":

Hierarchy Logical 1.jpeg

A hierarchy can be pictured as a pyramid of layers stacked on top of each other, or as in the screenshot below as a collapsible inverted tree.

Hierarchy Config file.PNG

The picture above is a screenshot of an example DO configuration file as seen in XMLnotepad. It presents the hierarchy in the classic two(2) panel "Norton Utilities user interface layout" in which the hierarchy is represented as a "collapsible tree" in the left panel and details of the "nodes" are displayed in the right hand panel.

The metadata of the DO is also stored in the database, (just like the metadata of a set of tables in a data-model of an RDBMS). Instances of data then conform to the metadata of the DO and are stored in the database. In this regard, (tables in data-models and DOs) are very similar. The difference is that a hierarchical data structure does not need to be joined, while the tables of the relational data-model do... and that makes a big difference to scaleability of applications using them.

Data objects contain fields

Creating data objects

Each DO is defined using an XML configuration file. This document describes the rules, data models, schemas, language, dependencies and references of the DO. It also has a generic description of the view, edit and list models.

Transforming data objects

Once a data object configuration file has been created, it is then transformed to create the following files:

Data model (JSON)
View model (JavaScript)
View (HTML and CSS)

Configuration files are transformed by making a call to the transformer service. This saves the data and view models into the config bucket on the server. More on transforming data objects.

Referencing data objects

Once transformed, data objects must then be referenced in the app configuration file for the app (or apps) in which they will be used. They must also be referenced in the workflow configuration file for the sub process and step(s) in which they will be accessed.

Data object instances

As the workflow is instantiated, a new instance of the data object (or data objects) in that workflow processes are created. The data associated with that data object instance is saved in the data object instance file. As other users interact with the data object through subsequent workflow steps, additional sequences of the same data object instance are created.

Updating and versioning data objects

Once you have created a data object and started using it to store data, you may need to make changes. Data objects may be versioned as you make updates. This separates the data entered by version to avoid inconsistencies.

Calculations in data objects

Overview of calculations and xpath functions