Data Model and Properties Definition

Properties can be defined for each component. Properties define the data model to be used in the component. For List Components or Grid Components (standalone or within a Master/Detail Component), information about the data model in which the data is provided by a Technical Process is mandatory. Within one Master/Detail Component, data is shared between the different components (see Properties in Master/Detail).

Properties are defined at the beginning of the component declaration within Properties:

XML

<DetailComponent>
    <Properties>
        <Property name="Person" type="Complex">
            <Property name="Vorname" type="String"/>
            <Property name="Nachname" type="String"/>
        </Property>
    </Properties>
    <FlowLayout>
        <Label value="#Person.Vorname"/>
		<Label value="#Person.Nachname"/>
    </FlowLayout>
</DetailComponent>

The data model defined here corresponds to the following scheme:

Possible attributes:

Attribute	Description
`displayName`	Display name of the property. Used in the column headers of Master/Detail Components, List Components and Grid Components. Possible values: Any string
`name`	Name of the property. Required. Possible values: Any string of alphanumeric characters (`a-z`, `A-Z`, `0-9`) Note that the property names `Component`, `OrderBy`, `Where`, `FileId`, `FileName`, `FileType`, `FileData`, `To`, `From` must not be used because they are preset and therefore validated.
`readOnly`	Restricts access to read-only. Possible values: `true` / `false`
`type`	Name of the property. Required. Possible values: `Base64`: Base64 encoded data `Boolean`: Boolean values `Color`: Hexadecimal color value `Complex`: Object contains other objects (nested properties). Used for list entries, for example. `Date`: Date specification in the ISO format `YYYY-MM-DD` (e.g. `2020-01-18`) `DateTime`: Date and time specifications in the format `YYYY-MM-DD'T'hh:mm:ss.fff` (e.g. `2019-01-01T01:00:00.000Z`) The date and time format must conform to ISO 8601. If no time zone is specified for a time entry, then the time zone of the server is used. On the server side, this time zone is then added. If a value with property type `DateTime` is used in a List Component, the specification of date and time is displayed in different ways depending on the existing values: If all values have the value `0` for seconds (`2020-01-01T00:00:00.000Z`), no seconds are displayed in the whole column. If at least one value has a value different from `0`, seconds are displayed in the whole column. The processing of the property type `DateTime` has changed with version 6.3. For all previous entries of the property type `DateTime`, as of version 6.3 not only the date but also the time is displayed! `Decimal`: Decimals `Image`: Graphic (Base64, resource in the folder Resources or external URL) If the graphic is stored as Base64 encoded string, the attribute `mediaType="image/"` must be defined. If the image is stored as an external URL, then the attribute `type="Image"` must also be specified. `Video`: Video (Base64, resource in the folder Resources* or external URL) `Integer`: Integers `List`: Contains list elements. Used for ComboBox and ListView. `String`: String `URL`: URL The XML data provided by the Technical Process have to contain the `type` and `externLinkTarget` attributes.

Data from the Technical Process

Data can be provided by a Technical Process, for example to generate lists dynamically. This data must correspond to the format defined by the properties. The data is bound to the UI elements using Data Binding. Within the XML file provided by a Technical Process, each element corresponds to a property. The value contained by the element is the value of the property.

XML

<Ok>
    <Person>
        <Vorname>Max</Vorname>
        <Nachname>Mustermann</Nachname>
    </Person>
</Ok>

The XML data provided by the Technical Process has either <Ok> or <OkList> as root element. <Ok> is used for Detail Components, <OkList> for List Components and Grid Components.

URL

The XML data provided by the Technical Process have to contain the type and externLinkTarget attributes.

Attribute Description

displayName

Display name that will be displayed instead of the record.

Possible values: Any string

type

Defines whether the URL is an internal or external link.

Possible values:

internal
external

externLinkTarget

Defines in which window the URL data type is opened.

Possible values:

same: The URL will be opened in the same window.
new: The URL will be opened in a new window.

Example for a simple properties definition

The following example shows a property named Example of type String.

XML

<DetailComponent>
	<Properties>
		<Property name="Example" type="String" />
	</Properties>
	<FlowLayout>
		...
	</FlowLayout>
</DetailComponent>

Example for a complex property definition

Properties can be nested. A property that contains one or more other properties is always of type Complex.

The following example shows a complex property:

Example for a complex property definition

XML

<DetailComponent>
    <Properties>
		<Property name="Example" type="String" />
        <Property name="Example2" type="Complex">
            <Property name="Internal" type="String"/>
            <Property name="Visible" type="Boolean"/>
        </Property>
    </Properties>
    <FlowLayout>
        <Label value="#Example"/>
        <Checkbox checked="#Example2.Visible" displayName="Visible"/>
        <Label value="#Example2.Internal" visible="#Example2.Visible"/>
    </FlowLayout>
</DetailComponent>

Example for a XML file with complex properties

XML

<Ok>
    <Example>Example</Example>
    <Example2>
        <Internal>Internal</Internal>
        <Visible>false</Visible>
    </Example2>
</Ok>

Example data binding

XML

<DetailComponent process="fillDetail.wrf">
    <Properties>

		...

    </Properties>
    <FlowLayout>
        <Label value="#Example" />
        <Checkbox checked="#Example2.Visible" displayName="Visible" />
        <Label value="#Example2.Internal" visible="#Example2.Visible" />
    </FlowLayout>
</DetailComponent>

Result

The result of this example is a detail component that displays data from detailData.xml:

Validation

Properties support validations. These allow to define rules that must apply to the values entered for properties.

To define validation rules, the Validation element must be used within the Property element. The Validation element can contain any number of Validation elements with validation rules and messages.

XML

<Property name="test" type="Integer">
    <Validations>
        <Validation>
            <Value operator="eq" expected="0" />
			<Message>The entered value is not correct.</Message>
        </Validation>
    </Validations>
</Property>

The above example shows a validation rule. This rule checks if the value specified for the property test is 0. The element Message is used to output a corresponding message.

Validations affect if the save action is active. If the validation is not passed, the save action within the component is not active. Therefore, components that contain invalid entries cannot be saved.

Possible validation types

The following validation types can be used as child elements within Validation:

Element	Description
`Contains`	Checks if a specific value is contained in a property value. The attribute `value` specifies the corresponding value.
`Email`	No attributes required. Checks if the property value is a valid email address.
`EndsWith`	Checks if the property value ends with a specific value. The attribute `postfix` specifies the corresponding value.
`Max`	Defines a maximum value for the property value. The attribute `value` specifies the corresponding value.
`MaxLength`	Defines a maximum string length for the property value. The attribute `value` specifies the corresponding value.
`Message`	Defines the message to be output as result of the validation.
`Min`	Defines a minimum value for the property value. The attribute `value` specifies the corresponding value.
`MinLength`	Defines a minimum string length for the property value. The attribute `value` specifies the corresponding value.
`Regex`	Checks if the property value matches a specific pattern. The attribute `pattern` specifies the corresponding pattern.
`Required`	No attributes required. Checks if the property value is not empty.
`StartsWith`	Checks if the property value starts with a specific value. The attribute `prefix` specifies the corresponding value.
`Value`	Checks using an operator (attribute `operator`) if the entered value corresponds to the expected value (`expected`).

Possible operators

Several operators are available for validation rules:

Operator	Description
`eq`	equal
`gt`	greater than
`gt_eq`	greater than or equal
`lt`	less than
`lt_eq`	less than or equal
`neq`	not equal

The attribute expected is the so-called control value. This value is used to apply the validation.

Example: <Value operator="gt" expected="0" /> means that the value of a property is checked to see if it is greater than 0.

Example logical operations

The following example shows how validations can be logical linked. If several rules are defined within a Validation element, they are linked with AND. If several Validation elements including rules are contained within a Validations element, then these are linked with OR.

Example validation

XML

<Property name="test" type="Integer">
	<Validations>
		<Validation>
			<Value operator="eq" expected="0" />
		</Validation>
		<Validation>
			<Value operator="gt_eq" expected="10" />
			<Value operator="lt_eq" expected="15" />
		</Validation>
	</Validations>
</Property>

In this example, the validation is passed, if the value of the property test equals 0 OR simultaneously is greater or equal 10 AND less or equal 15.

Example `<Message>`

A message can be defined within a Message element. This message is displayed in the input control to which the property to be validated is bound.

Please note the following specifications!

If the Message element is defined directly within the Validations element, the message is always displayed.
If no Message element is defined within the Validations elements, the messages defined in the appropriate Validation element will be displayed.
If no Message element is defined within the Validations element, all Validation elements must contain a message.

The message is defined directly within the Validations element:
Example: Message is specified directly within the validation element

XML
```
<Property name="test" type="Integer">
	<Validations>
		<Message>Please enter correct value</Message>
		<Validation>
			<Email/>
		</Validation>
	</Validations>
</Property>	
```
The above example results in the following messages:

Validation fails because no input was made.

Validation fails because no valid email address has been entered.
Validation is successful. No message is displayed.

For each validation rule a message is defined:

XML

<Validations>
<!-- <Message>Too long</Message> -->
    <Validation>
        <Message>End with fin and contains z</Message>
        <EndsWith postfix="fin" />
        <Contains value="z" />
    </Validation>
    <Validation>
        <Message>Too long</Message>
        <MaxLength value="10" />
    </Validation>
</Validations>

Data from the Technical Process

URL

Example for a simple properties definition

Example for a complex property definition

Possible validation types

Possible operators

Example logical operations

Example <Message>

Example `<Message>`