Some insight into element data handling
Whenever a configured form is loaded in Lobster Data Platform / Orchestration, the same technique is always used to populate elements with data.
This chapter goes relatively deep into the details about the functions and rules of this technique to explain certain data states that are often wrongly perceived as errors.
Element data and data structures are displayed in JSON format for easy visualization. When creating a form with randomly definable data fields, it is even recommended that the creator 'thinks' exclusively in such structures.
As mentioned before, the technique explained here applies to any configured form (input forms for business objects, portals/dashboards, ...). However, data fields of elements may not be (re-)assigned in all types of forms. Therefore, the context of Lobster Data Platform / Orchestration portals was chosen to illustrate the following explanations.
Form data, element data, values and data fields
Firstly, a number of concepts need to be introduced:
Each element in a configurable form may linked to a data field to define the source for the value of that element.
The expression form data refers to the data object that is the basis for populating a form.
Data that is referred to by an element as a source for its value is called element data.
Simple example for data fields and element data
Two text fields with the data fields text1 and text2 are created in the form.
With the help of the ribbon function 'Structure export', the data structure of the portal can be displayed.
{ "text1": "abc", "text2": "def"}The displayed JSON object { } corresponds to the form data. The fields text1 and text2 (defined via the data fields of the elements) are called values of the elements ('abc' and 'def').
Rule #1:
This simple example already shows a very important fact: Elements always read and write their data into the data of their parent element (in this case, the form data).
Rule #2:
If an element does not define its own data field, its data is the same as that of its parent element (no copy!). They are simply 'passed through' as an effect (in the above example this would be the case with the section element). Values of such an element can therefore not appear in the data structure of the portal.
This also means that elements that do not specify a data field, although they expect a value, do not display any value or display an 'odd' value.
The following example shows how a text field without a data field appears at runtime:
The text field displays '[object Object]' as a value, because it tries to load the data of the parent element (in this case an anonymous object { } ) as text. When converting an object into text, the result is the cryptic text '[object Object]'.
Furthermore, such fields would not load default values, since these are only considered if the data referenced by the data field is empty (null). However, an object is not considered empty (null) and therefore no default value is loaded.
Working with data fields
As mentioned above, the data field of an element specifies the 'key name' of the data to load into the element. A simple example with text1 and text2 was already shown above.
By nesting the elements in container elements, the form data is structured in a cascading manner. See the following example:
Element labels correspond to setting for data field (except 'Section').
The example configured above results in the following data structure:
{ "driver": { "firstname": "John", "lastname": "Smith" }}By nesting the elements, the data of the form is assembled in a cascading manner.
Alternatively, a data field can also be defined as a whole 'key' path. The parts of the path are separated from each other with dots '.'. See below (driver.):
Element labels correspond to setting for data field (except 'Section').
This configuration also results in the data structure shown above.
Accessing list data via the data field
If an element contains 'list data', a specific list element can also be addressed by adding an index number to the path in the data field.
Example:
A profile provides a list of vehicle parts for a specific order. The delivery note number, which is identical for all parts, should be output in a separate text field.
The form possesses a configured behaviour 'loadParts', which calls a profile that returns a list of vehicle parts referring to the same delivery note number (dn_number).
The first action to execute (on 'true') is 'Log to console', in order to display the return data of the profile to verify that the desired result is delivered to the actions. Opening the browser console (usually by pressing the F12 key). gives access to the logged data when running the portal. See sample output below:
By the following action, 'Populate element data', this list is loaded into the 'parts' container (which has no data field defined).
Since the text field contained in the 'parts' container is defined as data field 0.dn_number, it reads the 'dn_number' value of the first (0th) element of the list, as shown below.
