Simple use case: 'Clipboard for individual values'

The following example demonstrates the use of a variable element as a clipboard for simple values. A similar approach for storing complex element data is pointed out in the next section.

Objective:

A portal is used for entering a list (Repeatable element) of item data (in our example: text input for 'Goods description', 'Category'). Since this will typically involve multiple entries with similar goods descriptions, the portal should provide special copy & past functionality to minimize the typing effort:

• Shortcut F2 ('Copy') to copy the value of the current input field (in a variable representing the 'Clipboard')

• Shortcut F3 ('Paste') to paste the copied value to the current input field

• Shortcut F4 ('Populate column') to paste the copied value to any empty instances of the current input field

• Shortcut F5 ('Overwrite column') to paste the copied value to all instances of the current input field

• As indicated in screenshot these shorts help to generate versions (e.g. by color red/blue/green) by editing copies of a master or initial entry.

Configuration:

The 'Copy' interaction is initiated by a behaviour of an input field (here: 'Goods description') which responds to a Triggering event of the 'F2 pressed' type, which transfers the current input data to the variable element (here: 'Clipboard') by a Set value action:

• This type of behaviour must be configured for any of the repeated input elements of the list.

For the variable element a behaviour is configured, which responds to a Triggering event of the 'Changed' type by running a Behaviour 'Filled' to determine whether a container element featuring detailed instructions on available paste-shortcuts should be shown or hidden (actions Show element, Hide element):

• The instructions appearing at runtime also signals the presence of a value in the otherwise invisible 'Clipboard'.

• The specified Change types, 'Value set by program' applies for this purpose, because data is copied into the variable by a Set value action (see above) here, whereas the example in the next section uses Populate element data.

The various behaviours for pasting data also need to be configured for each individual input field. In the following, the configuration for 'Overwrite column' function is pointed out as an example to represent the group:

• Data is retrieved from the variable element 'Clipboard' by the Behaviour type Validate element.

• Returned data is assigned to all instances of the input field (a 'column' of the list) by running the Action type Set value with the option For duplicates also set.

Simple use case: 'Clipboard for element data'

This example demonstrates a use case similar to the previous example, where a variable is used as a clipboard for complex element data instead of simple values.

Objective:

A portal is used to generate 'Inventory reports' for items of a specific category ('Rims and wheels'). Each report may include separate lists per subcategory ('Sets of rims','Sets of wheels'). Within these lists each line of these lists features input fields describing an item and the related inventory count. Typically, items with similar features and description texts appear in the same report, so a copy & past functionality should be provided to transfer data from an existing row to another row for further editing.

As a wheel always includes a certain rim as a component, the rows for wheels contain rim descriptions. Copying a rim description into a wheel item should therefore be possible.

Configuration:

In this example the 'Copy' behaviour (named 'store') is defined for the Column layout ('rimRow'), which is the repeated element of the Repeatable element for 'Sets of rims'. This behaviour does not respond to any Triggering event, but is called by a Verhalten ausführen action from an instance of button 'Copy' inside this element.

• Element data from the repeated element ('Row') are determined by the Behaviour type Validate element. Therefore, the copy operation only works if the row does not contain 'invalid' fields. Our example does not refer to Validators or the 'Required' option for any field.

• If the Copy button is clicked in an input row with valid content, the Action type Populate element data transfers all content from a row into the variable element 'Clipboard'.
  ►IMPORTANT◄ The option As copy must be selected. Otherwise the variable element is assigned a reference to the source object data instead of 'real data'. In this case, changes applied to the source element would affect the value returned by the clipboard in paste operation.

The 'Paste' behaviour (named 'restore') is also defined by the repeated Column layout of the respective target container element. This behaviour is also called by a Verhalten ausführen action (not shown in picture) of button 'Paste' inside that element.

• Element data stored in the variable element 'Clipboard' is retrieved by the Behaviour type Validate element.

• It is 'Pasted' by a Populate element data Action type. The linked Target element is a Column layout ('rimData') without a data field (green highlight frame in screenshot), which contains the input fields describing the rim.
  ►IMPORTANT◄ The option Merge into original data (implies As copy) must be selected, so the data assigned to the 'rimData' container is merged into the parent data object. In the given context, the parent is the Column layout, which is the repeated element of the list of wheels (the red highlighted frame in the screenshot).

Runtime example:

• As a first step, a specific Set of rims was added to the respective list. The entered data was copied to the 'Clipboard' variable by clicking the Copy button.

• The copied data was the pasted into an existing entry for a Set of wheels, by clicking the Paste button in the target row.

• Existing input for Tyres and Quantity in this row is not affected by the 'Paste' operation, as these elements are not located inside the container for rim data ('rimData', see above).

• Data for Goods description and Branding are retrieved from the variable and merged into the data of the portal as outputfrom a 'Structure Export' shows:

►NOTE◄ The structure export also reveals, that the data transfer from the clipboard includes all data from the source container for rims, including the Quantity ('numberRims'), which appears next to the quantity of wheels ('numberWheels') in the data structure, because two distinct data field names were used. If, instead, both inputs would refer to the same data field name (e.g. 'number'), the 'structure export' might look like this:

• Element data from the rim in the variable element 'Clipboard' still specifies a value of 4 for data field 'number'. When pasted, this information is also merged into the data of the 'rimData' container. The Quantity field of the respective wheelset-row in the portal, which is also linked to data field 'number', keeps its value of 8, since it not located in the target container of the 'Paste'. However, when the form is validated to create the 'Structure export' the data field 'number' (precisely: wheelsets.line.number) receives a value of 4 at first (according to the invisible element data in the 'rimData' container) and afterwards is assigned the validation result (value 8) for the input field Quantity in the row element for the wheelset.

Simple use case: 'Returning complex data from an event handler'

The following example demonstrates the use of variable elements with a data field, for handling complex data returned from Event handling.

Scenario:

The purpose of a portal is to produce a limited 'abstract' of status history (working states and tracking states) for a business object, based on a reference number entered of scanned by the user. The provided reference code should identify a specific 'tool', whose life cycle is to be traced in Lobster Data Platform / Orchestration by recording working states and tracking states:

• Regarding Working state, only the current working state and the immediately preceding record should be featured by showing a specific symbol.

• Regarding Tracking state, a list of up to ten records should be presented in chronologically descending order, showing the localized tracking state code and the corresponding icon in separate columns.

Runtime sample:

To illustrate the objective the following screenshot shows sample output based on the configuration explained below:

Configuration (abstract):

►NOTE◄ The following description is limited to configuration details that are significant for understanding the use of the variable element.

• The Behaviour type 'getHistory' (right in screenshot) is triggered by a click on the Load status history button (see Triggering event Click).

• The Behaviour type Eigenes Aktionsevent auslösen (Formulardesigner) passes element data from the parent container 'Query' (green highlight frame in screenshot) to the custom action event 'WS/TS History'. This makes entered/scanned string from input field 'Tool reference' available as an object property (data field 'toolReferenceID') of the formData variable for an event handler (not described in detail here) responding to this event.

• The event handler performs a sequence of Search (Event action) calls to determine a business object addressed by the reference and – provided this produces a match at all – collect related Working state and Tracking state (more precisely: tracking state entries). Results from these searches for Working state and Tracking state are stored as lists by Set value actions in resepective object properties (WS_TRAIL, TS_TRAIL) of the formData variable. This data is returned to the Action on 'true' in the further course of the behaviour.

• The Action type Populate element data transfers this data to Target element 'Results', a Column layout (without a data field), containing two variable elements featuring data fields (WS_TRAILS, TS_TRAILS) corresponding with the object properties of the formData filled by the event handler. By this method, a single Custom action event may populate multiple 'data sources' in a form.

  • The option Merge into original data is not used here, since search results should only appear in the portal on screen an not in its data structure.

• Finally, the Action type Verhalten ausführen (collapsed in screenshot) is called twice to transfer data from each variable element to a corresponding Data grid via Grid: Füllen actions. The following screenshot shows the behaviour for tracking states as an example:
  
  

  

  • The Behaviour type Validate element gets the content from the variable element 'TrackingState_TRAIL' (green highlight in screenshot).

  • The Action type Grid: Füllen transfers this data to the Target element, here: a data grid 'Tracking state history' (red highlight frame in screenshot).