ReadContainer and WriteContainer
ReadContainers and WriteContainers form an abstraction level that allows you to define which data is displayed or where it is written on pages of an application. Data is read with ReadContainers and written with WriteContainers.
The "ReadContainers" and "WriteContainers" areas can be displayed or hidden using the "View" menu. If you select an application page in the application structure, the ReadContainer / WriteContainer area displays which containers have been defined for this page.
With ReadContainers, data from the data group that contains the current applications page are read. With WriteContainers, data can be written to any data group in the same application. You can also use custom ReadContainers and WriteContainers to integrate custom Java classes. Information on this subject is available in our Academy seminars.
ReadContainer
Every application page has exactly one ReadContainer for the data group in which it is contained. View pages at the top level of the application structure (i.e. directly beneath the application node) and pages in a system data group are the exceptions. These pages do not have a ReadContainer and one cannot be created for them.
In addition to the predefined ReadContainer on application pages in a data group, custom ReadContainers can be created that enable you to integrate custom Java classes.
Add ReadContainer
Opens a dialog where a new ReadContainer can be created.
Name
The name of a ReadContainer is usually the name of the data group that is the source of the data. The name can be modified but it has to be unique. If this is not the case, a notification will appear.
Type
The option "Custom class" can be selected as the type here. Any number of ReadContainers in this type can be created.
Custom class
Custom Java classes can be integrated here to read data from a specific database table, for example. More information on this subject is available in our Academy seminars.
Click "OK" to create a new ReadContainer and close the dialog again.
Edit ReadContainer
Click here for more information.
Delete ReadContainer
Deletes the currently selected ReadContainer.
Bindings
Bindings link the data read via the ReadContainer to the application elements on the page. Every element that has a binding is displayed in this list.
Delete binding
Deletes the binding currently selected.
Properties
For each ReadContainer, you can access the properties by clicking on "Edit".
In addition to the name of the ReadContainer, you will also find the type here. The following types are available:
-
Data group
This type is used for the default ReadContainer that is automatically created for each application page in a data group. The name of these ReadContainers is made up of the prefix "READ_" and the name of the respective data group. The data group type is basically used for containers that provide data from a data group.
-
Multi Input
This type is used for free layout tables contained on the current page. For each free layout table on the page, exactly one ReadContainer with the type "Multi Input" is automatically created where the table is located. The name of these ReadContainers is made up of the prefix "READ_" and the GUID of the free layout table. This also applies to WriteContainer.
-
Custom
This type is used for ReadContainers that integrate custom Java classes.
If the page is in a data group, you will also find the application and data group from which the data is read here in the ReadContainer properties.
Filter criteria
The source and destination of the ReadContainer is specified in the lower area of the properties. By clicking on "Edit filter criterion", you can access the filter settings for "Data group" and "User defined".
For the type "Data group", these have usually been correctly predefined already. The filter criteria inform the page which data record is to be displayed. The data restriction using filter criteria corresponds to the WHERE clause in the SELECT statement in the database request. As a page in a data group should only show one single data record, every possible combination of source and target values cannot be selected when editing the filter criteria. This means that a request cannot return more than one data record, which would cause an error when loading the page. In the case of "Multi-Input", the filter criteria are disabled, since the display of the data in a free layout table is controlled by the pages included in it.
The selector GUID can be copied to the clipboard by clicking the button on the right.
Source
The location of the value to be compared with the target values is defined here. The following sources may be considered:
-
Control - here you can select an application element on the page.
-
Data field - the desired ReadContainer can also be selected here
-
Session / Request / Processing context
-
Static value
-
Velocity script
-
Current user - the desired user data can be selected here
-
Other - you can store your parameter name here
Goal
Displays the target that is used to compare the value defined in the source. If these match, the corresponding data record is displayed.
WriteContainer
For each application page, a WriteContainer is automatically created for the data group in which it is located. WriteContainers can be created on all pages except for View pages at the top level of the application structure (i.e. directly beneath the application node). If there is no WriteContainer on a page, a data record cannot be deleted.
In addition to the already defined WriteContainer of application pages located in a data group, any number of WriteContainers can be created.
Add WriteContainer/ Edit WriteContainer
Opens a dialog where a new WriteContainer can be created or an existing WriteContainer can be edited.
Name
Enter a name for the WriteContainer here; this has to be unique. If this is not the case, a notification will appear.
Type
Select the desired type. "Data group" allows you to write data to any data group, even from other applications. If you select "Custom class", the appearance of the dialog will change.
Custom class
Custom Java classes can be integrated here. You can choose between a session value, a value in the SharedState or from a tenant (SelectedTenants). More information on this subject is available in our Academy seminars.
Click "OK" to create the new WriteContainer and close the dialog again.
Delete WriteContainer
Deletes the currently selected WriteContainer.
Bindings
Application elements, which have a binding, can be added or edited here. Elements can also be dragged from the workspace to the Bindings area via drag & drop.
Add Binding / Edit Binding
Click here for more information.
Delete binding
Deletes the binding currently selected.
Move up/ Move down
The arrow buttons can be used to change the order in which the bindings are processed.
Properties
The properties of WriteContainers correspond to those of ReadContainers.
Additionally, the WriteContainer contains the setting "Trigger process". The setting is already enabled when a WriteContainer is created. It causes data group event handlers, which listen to the same data group as the WriteContainer, to be started automatically when the "Add Record", "Save Record" or "Delete Record" actions are performed in the browser on the page containing the WriteContainer. If this setting is not activated, the event handler will not respond and the subsequent process steps will not be triggered. This is useful when constructing wizards that lead the users through multiple edit pages in the browser, for example. By activating the "Trigger workflow" setting, you can control that the event handler is only triggered when the Save button on the last page of the wizard is clicked on.
The source and destination of the ReadContainer is specified in the lower area of the properties. By clicking on "Edit filter criterion" you can access the filter settings for "Data group" and "User defined".
Filter criteria / Binding
This dialog is used for editing filter criteria and bindings.
The filter criteria inform the page which data record is to be saved. The data restriction using filter criteria corresponds to the WHERE clause in the UPDATE statement in the database request. As a page in a data group should only save one single data record, every possible combination of source and target values cannot be selected when editing the filter criteria. This means that a request cannot edit more than one data record, which would cause an error when saving the page. In the case of the "Multi-Input" type, the filter criteria are disabled, since the writing of the data in a free layout table is governed by the pages included in it.
Source
Displays the source of the filter criteria. The source corresponds to the value that should be used to filter the data in the data group. All the information about the different sources can be found here.
Goal
Displays the target that is used to compare the value defined in the source. If these match, the corresponding data record is used for saving the data.