Skip to main content
Version: 2.4

Config Data

Config Data Models and Config Data Sets allow designing data that can be used as configuration data. They behave like regular Data Models, in the sense that we can create Config Data Types with properties, and create relations between Config Data Types like we would do with regular Data Types.

The key difference is the lifecycle of the config data: those are created by the application developer at design time.

  • Data: data is what users use the application for. Data is typically created and modified by users, and it is used by users to take decisions and perform their work.
  • Config data: the config data is part of the application definition, like the application logic, its UI or like enums. It is statically defined by the application designer. Modifying the config data of an application in production typically requires pushing a new version of the application.

Config Data Model​

A Config Data model works exactly in the same way as a regular Data Model. Config Data Types can have properties, relations and inherit from other Config Data Types.

It is not possible to have relations between Config Data Types and regular Data Types.

Config Data Set​

Config Data Set allow creating, editing and deleting instances of Config Data Types. They are the equivalent of the Runtime Data Set for Config Data.

Samples uses​

Here are a few examples of using config data:

Define API endpoints and payloads​

One can have a Config Data Type to store e.g. the URL, verb and JSON payload template for various API calls. The JSON payload can be parameterized so that the proper values are inserted at every call. Such an approach has the benefit of centralizing the different APIs being used instead of having specific formats and data spread throughout the app.

Build generic Visual Components: datagrid​

A datagrid typically has a configuration for each column: which attribute must be displayed, its type, the order of the columns, their width, whether they can be sorted or not, etc. These configurations can be very well defined using a Config Data Type, with the actual instances defined in a Config Data Set.

Build generic Visual Components: application menu​

When building multiple applications for the same organization, a great speedup can be obtained by standardizing some UI elements such as the menu. Each app will have its own menu of course, some with more entries, some with less, but the actual behavior and look and feel of the menu can typically be standardized. A Config Data Type can be created with e.g. the label on the menu and its icon, and then each app can create its own Config Data Set with the specific list of menu entries.

More complex structures​

As Config Data Types can have relations with one anoter, it is also possible to define tree structures, for example to define the navigation with menus and submenus within an application.