light-forms.xml (Android only)

DynamicApp forms configuration can't be used for SAMO Mobile. Form definitions from model.xml are available for mobile app. It is recommended to use light-forms.xml extension for forms definitions to use the full mobile app possibilities. More common info about form logic in SAMO Mobile can be found in Forms in Mobile chapter.

Helpful documentation for every configuration element / attribute is also available in this generated TODO: reference guide.

Light forms configuration contains two main parts:

formSections - it is possible to define some section of the form in this configuration part and to reuse it across multiple form definitions
formDefinitions - main form configuration part

Example - top level structure:

<ber:formSections>
  <ber:formSection id="section1">
    <ber:section>
    ...
    </ber:section>
  </ber:formSection>
  <ber:formSection id="section2">
    <ber:section>
    ...
    </ber:section>
  </ber:formSection>
</ber:formSections>
<ber:formDefinitions>
  <ber:formDefinition>
  ...
  </ber:formDefinition>
  <ber:formDefinition>
  ...
  </ber:formDefinition>
</ber:formDefinitions>

formSections - collection of all shared form sections
formSection id - identifier of the form section. It is used for referencing the section in form definition
section - definition of the form section - syntax is same as in form definition - see section chapter below
formDefinitions - collection of all form definitions in the project
formDefinition - one form definition

Form Definition

One form definition can contain set of forms common for one or more feature types. Forms can be defined for different usages - creating new feature, editing existing feature, displaying feature details in readonly mode, form for use in specific tool, etc.

Example:

<ber:formDefinition name="Definition name">
  <!-- Optional interface form definition -->
  <!-- <ber:featureTypeArray formInterface="if_1"/> -->
  <ber:featureTypeArray>
    <ber:featureType xlink:href="model.xml#ft_1"/>
    <ber:featureType xlink:href="model.xml#ft_2"/>
  </ber:featureTypeArray>
  <ber:formArray>
    <ber:form>
    ...
    </ber:form>
    <ber:form>
    ...
    </ber:form>
  </ber:formArray>
  <ber:filterFormArray>
    <ber:filterForm>
    ...
    </ber:filterForm>
    <ber:filterForm>
    ...
    </ber:filterForm>
  </ber:filterFormArray>
</ber:formDefinition>

formDefinition name - form definition name - for documentation purposes only (for better orientation in the xml file - not used by mobile app)
featureTypeArray - collection of all feature types using this form definitions. More feature types can be defined here, if they have some common properties in model.xml

Hint: It is possible to define forms based on interface definition. In such case, the interface definition must be specified in model.xml and the id of the interface must be set in formInterface attribute in featureTypeArray. Collection of feature types must be empty in such case. See commented section in example above. Then such forms can be used for all feature types implementing the interface. In the form definition interface attributes can be used. It is possible to use also feature attributes or other components such related browse in interface form configurations, but such components will be visible only when particular feature type contains such attribute or relation that is used in the form.

Hint: Visibility and accessibility expressions in interface forms can be written using <ber:interfaceCondition> instead of <ber:condition>. The expression then uses interface attribute names and is evaluated polymorphically across all feature types implementing the interface. The optional typeConstraintMetaGroup attribute can additionally restrict the expression to a subset of feature types. See Attribute conditions in mobile.
formArray - collection of all forms defined for this form definition. Detailed description below.
filterFormArray - collection of all filter forms defined for this form definition. Filter forms are used for defining complex filters for browses. Common info about filtering in mobile is in Filtering chapter in Browse definition. Detailed description of filter forms syntax in Filter Form chapter below.

Form

Each form is based on one of 3 basic layouts:

simple layout - all components are in one single layout
tab control - components are organized into tabs
stepper - components are organized into steps

Tab control and stepper are always the top layout controls and it cannot be nested. Otherwise, simple layout is basic layout that can be used as a top layout of the form by itself or it is used as a layout inside tab control or stepper (inside tab or step).

Example:

<ber:form id="formId1" name="Form name" readOnly="true" defaultFormSize="fullScreen" usage="detail,edit">
  <ber:formHeader showMobileSimple="true"/>

  <!-- only one of the top layouts -->
  <ber:tabControl>
  ...
  </ber:tabControl>

  <ber:stepper>
  ...
  </ber:stepper>

  <ber:simpleLayout>
  ...
  </ber:simpleLayout>
</ber:form>

form id - form identifier - it is used for referencing the form if necessary (e.g. in Tool parameters or in protocols.xml)
form name - form name - it can be used in mobile app on some places (e.g. in filter forms menu)
form readOnly - optional true / false attribute - if true, the form is opened in readonly mode. Default value is false, except the detail usage, where default value is true.
form usage - optional attribute defining in which usage the form can be used. More comma separated values can be defined. Possible values are:
- edit - form can be used for editing existing feature
- detail - form can be used to display feature details in read-only mode
- some other specific usage - function-specific usages can be defined in the application. It is documented in corresponding chapters.
  - one of such specific usage is form definition for editing feature during workflow transition. When there is a need to fill some feature attributes during workflow transition, light form can be defined with following usage syntax: "workflow:transitionId" where workflow is a static keyword and transitionId is id of the workflow action.
Note: This usage attribute can be omitted - especially in cases when it is used by a function that uses its form ID

Note: When the form is used for creating new feature, the edit usage must be defined here. It is not possible to define separate form for creating new feature by now.
form defaultFormSize - optional attribute defining which form size will be used by default. Possible values are:
- auto - (default) form has dialog size on big displays or fullscreen on small
- fullScreen - form has always fullscreen size
formHeader showMobileSimple - optional configuration. Feature info is displayed in the form header by default. It is possible to show all feature attributes defined in model.xml form definition with mobileSimple usage in the form header by specifying true value for the showMobileSimple attribute.
top level layout - one of the top level layouts must be defined in the form (tabControl, stepper, simpleLayout) - see below

Tab Control

One of the base form layouts. It contains set of tabs. User can freely switch between tabs. Each tab can contain only one layout - simple layout.

Example:

<ber:tabControl>
  <ber:tab label="Tab 1">
    <ber:icon xlink:href="resource.xml#ic_1"/>
    <ber:visibility visible="false">            
      <ber:condition>'at_1' = 1</ber:condition>
    </ber:visibility>
    <ber:accessibility readOnly="true">
      <ber:condition>'at_1' = 1</ber:condition>
    </ber:visibility>
    <ber:simpleLayout>
    ...
    </ber:simpleLayout>
  </ber:tab>
  <ber:tab label="Tab 2">
    <ber:icon xlink:href="resource.xml#ic_1"/>
    <ber:simpleLayout>
    ...
    </ber:simpleLayout>
  </ber:tab>
</ber:tabControl>

tab label - tab name displayed in the application
icon - optional reference to icon displayed on the tab - see Icons in mobile

Note: Tab label or icon must be defined. When both are defined, both are displayed.

visibility - optional configuration for conditional tab visibility. Condition can be included in more places in mobile configuration and it has common syntax for all mobile configuration parts. For more info see Attribute conditions in mobile.
visibility visible - true / false attribute. If false, the tab is hidden when the condition is fulfilled. If true, the tab is visible only when the condition is fulfilled.
accessibility - optional configuration for conditional tab accessibility. Condition can be included in more places in mobile configuration and it has common syntax for all mobile configuration parts. For more info see Attribute conditions in mobile.
accessibility readOnly - true / false attribute. If true, the tab is readonly when the condition is fulfilled. If false, the tab is editable only when the condition is fulfilled.

Hint: Both visibility and accessibility can use the optional typeConstraintMetaGroup attribute on <ber:condition> or the alternative <ber:interfaceCondition> element for forms shared across multiple feature types — see Attribute conditions in mobile.

simpleLayout - layout of the tab - see Simple layout chapter below

Stepper

One of the base form layouts. It contains set of steps. User can switch between steps only in defined order (forward or backward). Each step can contain only one layout - simple layout.

Configuration and possibilities for stepper is similar to tab control configuration. Only difference is that there are steps instead of tabs and stepper is used instead of tabControl.

Simple Layout

Simple layout can be used as a top level layout of the form or as a layout inside tab or step in tab control or stepper. It is a base layout that can contain set of various components. Components are organized into sections. Sections can be nested recursively.

So, there is always one simple layout. Inside the simple layout there must be a collection of sections. Each section can contain either collection of inside sections or collection of components.

By default, all sections are arranged vertically one below the other. Also all components in section are arranged vertically one below the other by default. There is a possibility to arrange sections and components horizontally next to each other. More about horizontal form layout is in Horizontal form layouts chapter.

Example:

<ber:simpleLayout layout="horizontal" readOnly="true">
  <ber:toolBar>
  ...
  </ber:toolBar>
  <ber:sectionArray>
    <ber:section>
    ...
    </ber:section>
    <ber:section>
    ...
    </ber:section>
    <ber:sectionRef refId="section1"/>>
  </ber:sectionArray>
</ber:simpleLayout>

simpleLayout layout - optional attribute defining arrangement of sections in the layout. More info in Horizontal Form Layouts chapter. Default value is vertical.
simpleLayout readOnly - optional true / false attribute - if true, all components in the layout are readonly. Default value is false.
toolBar - optional toolbar configuration. Toolbar is displayed in the bottom of the layout. It can contain tools and feature tools. More info in Toolbars in Mobile chapter.
sectionArray - collection of all sections in the layout.
section - definition of one section.
sectionRef refId - reference to shared section defined in formSections part of the configuration. It is possible to use shared section in more forms.

Section

Each section can be collapsibe, it can contain header, toolbar and either collection of inside sections or collection of components. Section can be conditionally visible or readonly.

Example:

<ber:section layout="horizontal" isCollapsible="collapsed">
  <ber:sectionArray>
    <ber:section header="Section name 1" minWidth="30">
      <ber:icon xlink:href="resource.xml#ic_1"/>
      <ber:toolBar>
      ...
      </ber:toolBar>
      <ber:visibility visible="true">
        <ber:condition>'at_1' = 0</ber:condition>
      </ber:visibility>
      <ber:itemArray>
      ...
      </ber:itemArray>
    </ber:section>
    <ber:section header="Section name 2" readOnly="true">
      <ber:icon xlink:href="resource.xml#ic_1"/>
      <ber:accessibility readOnly="true">
        <ber:condition>'at_2' != 1</ber:condition>
      </ber:accessibility>
      <ber:itemArray>
      ...
      </ber:itemArray>
    </ber:section>
  </ber:sectionArray>
</ber:section>

section layout - optional attribute defining arrangement of inside sections or components in the section. More info in Horizontal Form Layouts chapter. Default value is vertical.
section minWidth - optional attribute defining minimal width of the section in application units. It is useful only when combined with horizontal layout. More info in Horizontal Form Layouts chapter.
section isCollapsible - optional attribute defining if the section is collapsible. Possible values are:
- collapsed - section is collapsible and collapsed by default
- true - section is collapsible nad not collapsed by default
- false - section is not collapsible (Default value)
section header - optional section name displayed in the application as section header
icon - optional reference to icon displayed in the section header - see Icons in mobile
toolBar - optional toolbar configuration. Toolbar is displayed in the section header. It can contain tools and feature tools. More info in Toolbars in Mobile chapter.
visibility - optional configuration for conditional section visibility. Condition can be included in more places in mobile configuration and it has common syntax for all mobile configuration parts. For more info see Attribute conditions in mobile.
visibility visible - true / false attribute. If false, the section is hidden when the condition is fulfilled. If true, the section is visible only when the condition is fulfilled.
accessibility - optional configuration for conditional section accessibility. Condition can be included in more places in mobile configuration and it has common syntax for all mobile configuration parts. For more info see Attribute conditions in mobile.
accessibility readOnly - true / false attribute. If true, the section is readonly when the condition is fulfilled. If false, the section is editable only when the condition is fulfilled.

Hint: Section visibility and accessibility support the same condition extensions as tab visibility — typeConstraintMetaGroup and <ber:interfaceCondition>. See Attribute conditions in mobile.

sectionArray - collection of all inside sections in the section. It is used when the section contains other sections.
itemArray - collection of all components in the section. It is used when the section contains components.

Form Components

There are various components that can be used in the form. Each component has its own configuration. Common attributes for all components are:

label - optional component label displayed in the application
readOnly - optional true / false attribute - if true, the component is readonly. Default value is false.
minWidth - optional attribute defining minimal width of the component in application units. It is useful only in combination with horizontal layout. More info in Horizontal Form Layouts chapter.
visibility - optional configuration for conditional component visibility. Condition can be included in more places in mobile configuration and it has common syntax for all mobile configuration parts. For more info see Attribute conditions in mobile.
accessibility - optional configuration for conditional component accessibility. Condition can be included in more places in mobile configuration and it has common syntax for all mobile configuration parts. For more info see Attribute conditions in mobile.

Hint: Component visibility and accessibility — like all other condition usages in light forms — support the optional typeConstraintMetaGroup attribute on <ber:condition> and the alternative <ber:interfaceCondition> element. These are particularly useful in forms defined for an interface (formInterface in featureTypeArray) or shared across multiple feature types.

The list of all available components is in the following table. Meaning of columns:

Form component - type of UI component
Lids model representation - representation of the component in model.xml
Tag - tag element name of the component in light-forms.xml
Minimal width - default minimal width of the component in application units. It is useful only in combination with horizontal layout. More info in Horizontal Form Layouts chapter. It is possible to override the default value by minWidth attribute of the component.

Form component	Lids model representation	Tag	Minimal width in application units
Feature attribute editor	feature attribute	attributeInput	20
List of related features	relation type	relatedBrowse / relations	2x attributeInput
List of features		browse	2x attributeInput
List of attachments	attachment types	attachments	2x attributeInput
List of details	detail type	details	2x attributeInput
Protocols	related feature types + protocols.xml extension	protocols	1x relatedBrowse
Business workflow actions	business server workflow for feature type	workflow	1.5x attributeInput
Signature	feature attribute	signature	1x attributeInput
Static text - annotations		annotation	2x attributeInput
Toolbar		toolBar	2x attributeInput
LIDS form	standard form in model.xml	lidsForm	max of minWidth content

Feature Attribute Editor

This component is used for editing feature attribute value. The attribute must be defined in model.xml for the feature type that the form is intended for. Used UI component depends on the attribute data type and it is determined automatically by the application, but it can be changed by configuration in some cases. Common configuration options for this component:

xlink:href - reference to feature attribute in model.xml. It is mandatory.
mandatory - optional true / false attribute - if true, the attribute value must be filled in. Default value is false and it means - use mandatory definition from model.xml.

Hint: It is not possible to define an attribute as optional in the form, if it is defined as mandatory in model.xml.
defaultValue - optional attribute defining default value of the attribute when creating new feature. It can be used to override default value defined in model.xml.
annotation - optional component for static text displayed below the input field. It can be used for hints or other info for user. It is possible to use placeholders with attribute ids to include some feature values in the hint.
attributeConstraint - optional component for defining additional constraints for the attribute value. When the constraint is not fulfilled, coresponding error message is displayed behind the field, but user is able to save the form.
nullValueLabel - optional attribute defining label of the option for setting attribute value to null

Examples:

Simpliest attribute editor configuration - default UI component is used based on attribute data type. Label from model.xml attribute definition is used.

<ber:attributeInput xlink:href="model.xml#at_1"/>

Complex example with all possible common options:

<ber:attributeInput label="Label:" mandatory="true" nullValueLabel="No value" xlink:href="model.xml#at_2">
  <ber:defaultValue>0</ber:defaultValue>
  <ber:attributeConstraint>
    <ber:condition>'at_1' != 0 OR 'at_2' = 1</ber:condition>
    <ber:message>Illegal combination of values</ber:message>
  </ber:attributeConstraint>
  <ber:annotation>
    <ber:content>Previous value: %%at_previousValue%%</ber:content>
  </ber:annotation>
</ber:attributeInput>

Next chapters describe in detail default UI components and other configuration options for particular attribute data types.

Feature attribute data type string

Default component is multi-line text input. There are some options available for string input, that can change which component is used:

Option	Component used	Description
allowedValues	ComboBox	Possible string values to fill in the input can be defined
radioButtonEditor	RadioButton	When allowed values are defined, they can be represented as radio buttons

Examples:

<ber:attributeInput xlink:href="model.xml#at_2">
  <ber:allowedValues>Value 1;Value 2</ber:allowedValues>
</ber:attributeInput>

<ber:attributeInput xlink:href="model.xml#at_2">
  <ber:allowedValues>Value 1;Value 2</ber:allowedValues>
  <ber:radioButtonEditor/>
</ber:attributeInput>

Feature attribute data type number

Default component is numeric input. There are same options available for numeric input as for string input with same behaviour.

Option	Component used	Description
allowedValues	ComboBox	Possible numeric values to fill in the input can be defined
radioButtonEditor	RadioButton	When allowed values are defined, they can be represented as radio buttons

Examples:

<ber:attributeInput xlink:href="model.xml#at_3">
  <ber:allowedValues>1;2</ber:allowedValues>
</ber:attributeInput>

<ber:attributeInput xlink:href="model.xml#at_3">
  <ber:allowedValues>1;2</ber:allowedValues>
  <ber:radioButtonEditor/>
</ber:attributeInput>

Feature attribute data type date / short date

Default component is datetime picker / date picker. No other options are available for this input.

Feature attribute data type small codelist

Default component is comboBox. There are some options available for this input, that can change which component is used:

Option	Component used	Description
allowedValues	ComboBox	Possible values (primary keys) to limit the codelist values
radioButtonEditor	RadioButton	Codelist values can be represented as radio buttons

Examples:

<ber:attributeInput xlink:href="model.xml#at_4">
  <ber:radioButtonEditor/>
</ber:attributeInput>

<ber:attributeInput xlink:href="model.xml#at_4">
  <ber:allowedValues>0;1</ber:allowedValues>
</ber:attributeInput>

<ber:attributeInput xlink:href="model.xml#at_4">
  <ber:allowedValues>0;1</ber:allowedValues>
  <ber:radioButtonEditor/>
</ber:attributeInput>

Feature attribute data type large codelist / hierarchical codelist

Default component is selection list / selection tree. No other options are available for this input.

Feature attribute data type checkboxed codelist

Default component is check box. There are some options available for this input, that can change which component is used:

Option	Component used	Description
radioButtonEditor	RadioButton	Codelist values can be represented as radio buttons

Examples:

<ber:attributeInput xlink:href="model.xml#at_5">
  <ber:radioButtonEditor/>
</ber:attributeInput>

Feature ref attribute

Default component is feature selection list. There are some options available for this input.

Option	Component used	Description
featureRefEditor	selection list	Additional condition can be used to filter target features to link to this attribute

Examples:

<ber:attributeInput xlink:href="model.xml#at_6">
  <ber:featureRefEditor>
    <ber:condition>...</ber:condition>
  </ber:featureRefEditor>
</ber:attributeInput>

Attributes of the target feature type must be used in the condition. Variables are allowed in the condition including "THIS" variable representing the source feature. The condition supports also the optional typeConstraintMetaGroup attribute and the alternative <ber:interfaceCondition> element — useful when the FeatureRef attribute can target multiple feature types. More about condition syntax can be found in the Attribute conditions in mobile chapter.

Colored radio buttons

It is possible to define colors for particular values in radio buttons. Circle selection buttons can be colored depending on configuration. It is possible only for codelist attributes. The color of individual codelist values must be stored in some codelist column as hexadecimal RGB value. So, new codelist column must be added to codelist definition in model.xml and the RGB values should be added to codelist content in form “#RRGGBB” (e.g. “#FF0000” – red color). Please see UX/UI chapter for more info about colors in mobile app.

There are two possible layouts of radio button values:

vertical layout – all radio button values are arranged vertically one below the other - it is the same layout as for standard radio buttons - but colors are used
horizontal layout – all radio button values are arranged horizontally next to each other - in this case - there is no space for labels of the values - so only colored circles are displayed. Users can tap a circle to select a value. The label of the attribute is displayed above the colored circles. It is recommended to use attribute input annotation component below the colored circles to explain the meaning of particular colors.

Examples:

<ber:attributeInput xlink:href="model.xml#at_1">
  <ber:radioButtonEditor>
    <ber:colorDefinition>
      <ber:colorCodelistAttribute xlink:href="model.xml#ca_006_color"/>
    </ber:colorDefinition>
  </ber:radioButtonEditor>
</ber:attributeInput>

<ber:attributeInput xlink:href="model.xml#at_1">
  <ber:radioButtonEditor>
    <ber:colorDefinition buttonsStyle="horizontal">
      <ber:colorCodelistAttribute xlink:href="model.xml#ca_006_color"/>
    </ber:colorDefinition>
  </ber:radioButtonEditor>
  <ber:annotation>
    <ber:content>RED - Critical, ORANGE - High, GREEN - Low</ber:content>
  </ber:annotation>
</ber:attributeInput>

colorDefinition buttonsStyle - optional attribute defining layout of the radio button values. Possible values are:
- vertical - all radio button values are arranged vertically one below the other (Default value)
- horizontal - all radio button values are arranged horizontally next to each other
colorCodelistAttribute - reference to codelist attribute in model.xml containing RGB color values for particular codelist values

Hint: It is possible to create "table" layout of colored radio buttons by using horizontal layout of radio button values for more feature attributes binded to the same codelist with common annotation section:

Example:

<ber:itemArray>
  <ber:annotation>
    <ber:content>Green = Yes, Red = No, Grey = No value</ber:content>
  </ber:annotation>
  <ber:attributeInput xlink:href="model.xml#at_check1_pass">
    <ber:radioButtonEditor>
      <ber:colorDefinition buttonsStyle="horizontal">
        <ber:colorCodelistAttribute xlink:href="model.xml#ca_006_color"/>
      </ber:colorDefinition>
    </ber:radioButtonEditor>
  </ber:attributeInput>
  <ber:attributeInput xlink:href="model.xml#at_check2_pass">
    <ber:radioButtonEditor>
      <ber:colorDefinition buttonsStyle="horizontal">
        <ber:colorCodelistAttribute xlink:href="model.xml#ca_006_color"/>
      </ber:colorDefinition>
    </ber:radioButtonEditor>
  </ber:attributeInput>
</ber:itemArray>

This component is used for displaying and managing list of related features. The relation types must be defined in model.xml for the feature type that the form is intended for. There are two types of components:

relatedBrowse - this component can be used only for one particular relation type. More components of this type can be used in the form definition for different relation types.
relations - this component can be used for managing all relation types that can be used in mobile app for the particular feature type.

relatedBrowse

This component is used for displaying and managing list of related features for one particular relation type. It is possible to define some additional filtering, ordering, browse configuration and map component configuration for the related features list. The condition supports also the optional typeConstraintMetaGroup attribute. More about condition syntax can be found in the Attribute conditions in mobile

Example:

<ber:relatedBrowse>        
  <ber:relationAssoc xlink:href="model.xml#as_1"/>
  <ber:relationRole xlink:href="model.xml#rt_1"/>
  <ber:condition>'at_1' = 1</ber:condition>
  <ber:orderByArray>
    <ber:orderBy direction="descending" xlink:href="model.xml#at_2"/>
  </ber:orderByArray>
  <ber:browseConfig>
  ...
  </ber:browseConfig>
  <ber:mapComponent xlink:href="samo-mobile.xml#mapCompRelated" defaultVisible="true">
    <ber:parameterArray>
       <ber:parameter name="defaultVisible" value="true"/>
       <ber:parameter name="layerSelection" value="true"/>
    </ber:parameterArray>
  </ber:mapComponent>
</ber:relatedBrowse>

relationAssoc - mandatory reference to association type in model.xml defining the relation type
relationRole - mandatory reference to relation role in model.xml defining the target relation role type
condition - optional condition for additional filtering related features. Condition can be included in more places in mobile configuration and it has common syntax for all mobile configuration parts. For more info see Attribute Conditions in Mobile.
orderByArray - optional collection of attributes defining ordering of related features in the list
- orderBy - reference to feature attribute in model.xml defining one ordering attribute. More attributes can be defined here.
- orderBy direction - optional attribute defining ordering direction. Possible values are ascending (default) and descending
browseConfig - optional configuration of the browse component used for displaying related features list. More info in Browse configuration chapter.
mapComponent - optional reference to map component defined in samo-mobile.xml extension. Simple map component can be integrated to the list of related features It is used for displaying related features on the map. More info in Map components chapter.
mapComponent defaultVisible - optional true / false attribute - if true, the map component is visible by default. Default value is false. Map component can be shown / hidden by user in the application.
- parameterArray - optional collection of parameters for the map component. Possible parameter names:
  - layerSelection - true / false parameter - if true, user can select layers visibility in the map component. Default value is false.

relations

This component is used for displaying and managing list of related features for all relation types that can be used in mobile app for the particular feature type. Set of relation types can be limited for given feature type by defining metadata group id in groupArray of samo-mobile.xml - see Relationships chapter.

Example:

<ber:relations allowAdd="false" allowDelete="false"/>

allowAdd - optional true / false attribute - if true, user can add new relations. Default value is true.
allowDelete - optional true / false attribute - if true, user can delete existing related feature. Default value is true.

List of Features

This component is used for displaying list of features based on some filtering and ordering. It is similar to relatedBrowse component, but it is not limited to related features. It is possible to define some additional filtering, ordering, browse configuration and map component configuration for the features list. Configuration is nearly the same as for screen Browse Definition in samo-mobile.xml.

Example:

<ber:browse>
  <ber:dataSource>
    <ber:filter>
      <ber:featureTypeArray>
        <ber:featureType xlink:href="model.xml#ft_2"/>
      </ber:featureTypeArray>
      <ber:condition>'ft2_at_1' = '%%THIS.at_1%%' AND 'ft2_at_2' = 0</ber:condition>
    </ber:filter>
    <ber:orderByArray>
      <ber:orderBy direction="descending" xlink:href="model.xml#at_boPracovnyPrikaz_datumRealizacie"/>
    </ber:orderByArray>
  </ber:dataSource>
  <ber:browseConfig allowDetail="false" allowModification="false" allowFilter="false">
  ...
  </ber:browseConfig>
</ber:browse>

Description of all configuration elements is in Browse Definition chapter.

Note: Variable with THIS prefix can be used in condition at this place. THIS represents the feature that the form is currently displayed for. Configuration above means - display in this component list of all features of type ft_2, where attribute ft2_at_1 is equal to value of attribute at_1 of the feature that the form is displayed for and where attribute ft2_at_2 is equal to 0.

List of Attachments

This component is used for displaying and managing list of attachments of the feature. Attachment types must be defined in model.xml for the feature type that the form is intended for.

Example:

<ber:attachments allowAdd="true" allowDelete="true"/>

allowAdd - optional true / false attribute - if true, user can add new attachments. Default value is false.
allowDelete - optional true / false attribute - if true, user can delete existing attachments. Default value is false.

List of Details

This component is used for displaying and managing list of details of the feature. Detail association types must be defined in model.xml for the feature type that the form is intended for.

Example:

<ber:details/>

No additional configuration is available for this component.

Protocols

This component is used for displaying and managing list of protocols related to the feature. Protocols must be defined as feature types in model.xml with relation types to feature type that the form is intended for. Protocol configuration is needed in protocols.xml extension.

This component displays list of all protocols related to the form feature. Component is similar to relatedBrowse component, but the list of protocol features is filled depending on protocols.xml. Standard browse configuration can be used in this component. So, grouping, ordering, filtering, toolbars and card customization can be used here.

Moreover, user is able to create new protocol. Menu for creating new protocol is filled based on protocols.xml configuration. User can create only such protocol types that are defined in protocols.xml for the particular feature type and for the particular attribute values of the form feature.

Example:

<ber:protocols>
  <ber:browseConfig>
  ...
  </ber:browseConfig>
</ber:protocols>

browseConfig - optional configuration of the browse component used for displaying protocols list. More info in Browse configuration chapter.

Business Workflow Actions

This component is used for displaying workflow state and workflow actions for the feature. Business workflow must be defined on the server side for the feature type that the form is intended for. Component contains current workflow state and list of possible actions that can be performed in the current state. User can select one of the actions and perform it. After action is performed, the workflow state is updated and new possible actions are displayed.

Example:

<ber:workflow/>

No additional configuration is available for this component.

Signature

This component is used for displaying and capturing signature that can be saved to the feature. The attribute for storing the signature must be defined in model.xml for the feature type that the form is intended for. Attribute data type must be string with sufficient length. Signature is stored as base64 encoded PNG image.

Example:

<ber:signature label="Signature">
  <ber:featureAttribute xlink:href="model.xml#at_6"/>
</ber:signature>

featureAttribute - mandatory reference to feature attribute in model.xml for storing the signature

Static Text - annotations

This component is used for displaying static text in the form. It can be used for various purposes - hints, instructions, section description, etc. It is possible to use placeholders with attribute ids to include some feature values in the text.

Example:

<ber:annotation>
  <ber:content>Some annotation text.</ber:content>
</ber:annotation>

No additional configuration is available for this component.

Toolbars in light forms cannot be configured as standalone component. Toolbar can be included in simple layout, in section, in browseConfig and is described in corresponding chapters.

LIDS Form

This component is used for including standard LIDS form defined in model.xml into light form. This possibility should be used only in cases where a common form configuration exists in model.xml reusable for desktop, web and mobile clients and when there is no need for mobile specific form. LIDS form is included into light form definition as a one whole component and there is no possibility to configure some parts of it.

Example:

<ber:lidsForm allowEdit="false" xlink:href="model.xml#fmd_1"/>

allowEdit - optional true / false attribute - if true, user can edit attributes in the form. Default value is true. It can be set to false in case when the form is used for displaying details only.
xlink:href - mandatory reference to standard form definition in model.xml

Filter form is a special type of light form used for creating a user defined filter for filtering features in the list. Filter forms can be used in browse screens (standardBrowse, workOrders, allocations). filterFormArray can be added to Browse Definition with references to filter forms that can be used for filtering features in the particular browse screen.

Note: Filter form configuration section in light-forms.xml is always a part of some formDefinition and is related to feature types included in this definition. Filter form can contain only feature attributes of these feature types. Browse screen with filter form reference should be defined for the same feature types as the filter form.

Filter form configuration is similar to standard light form configuration. There are some limitations and differences:

It is possible to use only attributeInput component for feature attribute conditions in itemArray. Other components are not allowed (don't make sense).
- It is also not possible to use toolBar component in any place in filter form
- annotation component is only exception - it can be used for static text in filter form.
"layout" components can be used same way as in standard light form definition - tabControl, stepper, simpleLayout, section.
filterForm element is used instead of form element
attributeFilter element is used instead of attributeInput element

Filter form is not used for creating or editing features, so there is no need to define form usage. Filter form is always used to create user defined attribute condition. Each attributeFilter field defines one part of the expression: featureAttribute - operator - value. All attributeFilter fields are combined together with AND operator to create final filter expression.

Each attribute filter field contains reference to feature attribute and based on attribute data type, default operator and default input component for value is used. Field operator can be changed by configuration in attributefilter definition. User can't change the operator interactively. User is able only to fill in the input value.

Default and other possible operators and input components are described in the following chapters for each feature attribute data type.

Feature attribute data type string

Attribute can be used in filter forms. It's default operator is contains and default component is TextInput. Other operators that can be used:

contains	equals	greaterThan	lessThan	isIn	between
✅	✅	❌	❌	❌	❌

Feature attribute data type number

Attribute can be used in filter forms. It's default operator is equals and default component is NumericInput. Other operators that can be used:

equals	greaterThan GreaterThanOrEquals	lessThan lessThanOrEquals	isIn	between
✅	✅	✅	❌	❌

Feature attribute data type date / short date

Attribute can be used in filter forms. It's default operator is between and default component is dateTimePicker. Other operators that can be used:

equals	greaterThan GreaterThanOrEquals	lessThan lessThanOrEquals	isIn	between
❌	✅	✅	❌	✅

Feature attribute data type small codelist

Attribute can be used in filter forms. It's default operator is isIn and default component is checkBoxes. Other operators that can be used:

equals	greaterThan GreaterThanOrEquals	lessThan lessThanOrEquals	isIn	between
✅	❌	❌	✅	❌

Feature attribute data type large codelist / hierarchical codelist

Attribute can be used in filter forms. It's default operator is equals and default component is selectionList. Other operators that can be used:

equals	greaterThan GreaterThanOrEquals	lessThan lessThanOrEquals	isIn	between
✅	❌	❌	✅	❌

Feature attribute data type checkboxed codelist

Attribute can be used in filter forms. It's default operator is isIn and default component is checkBox, which can have three possible values: Anything, true, false. Other operators that can be used:

equals	greaterThan GreaterThanOrEquals	lessThan lessThanOrEquals	isIn	between
✅	❌	❌	✅	❌

Feature ref attribute

Attribute can be used in filter forms. It's default operator is equals and default component is featureRefPicker. Other operators that can be used:

equals	greaterThan GreaterThanOrEquals	lessThan lessThanOrEquals	isIn	between
✅	❌	❌	❌	❌

Examples:

<ber:filterFormArray>
  <ber:filterForm id="filterSimple" name="Simple filter" usage="">
    <ber:simpleLayout>
      <ber:sectionArray>
        <ber:section layout="horizontal">
          <ber:itemArray>
            <ber:attributeFilter label="Attribute 1 is" xlink:href="model.xml#at_1"/>
            <ber:attributeFilter label="Attribute 2 is" xlink:href="model.xml#at_2"/>
          </ber:itemArray>
        </ber:section>
      </ber:sectionArray>
    </ber:simpleLayout>
  </ber:filterForm>
  <ber:filterForm id="filterComplex" name="Complex filter" usage="">
    <ber:tabControl>
      <ber:tab label="Tab1 label">
        <ber:icon xlink:href="resource.xml#ic_1"/>
        <ber:simpleLayout>
          <ber:sectionArray>
            <ber:section>
              <ber:itemArray>
                <ber:attributeFilter label="Attribute 3 equals" operator="equals" xlink:href="model.xml#at_3"/>
                <ber:attributeFilter label="Attribute 4 is in" operator="isIn" xlink:href="model.xml#at_4"/>
              </ber:itemArray>
            </ber:section>
          </ber:sectionArray>
        </ber:simpleLayout>
      </ber:tab>
      <ber:tab label="Tab2 label">
        <ber:icon xlink:href="resource.xml#ic_2"/>
        <ber:simpleLayout>
          <ber:sectionArray>
            <ber:section>
              <ber:itemArray>
                <ber:attributeFilter label="Attribute 5 contains" operator="contains" xlink:href="model.xml#at_5"/>
                <ber:attributeFilter label="Date attribute between" operator="between" xlink:href="model.xml#at_6"/>
                <ber:attributeFilter xlink:href="model.xml#at_7"/>
                <ber:attributeFilter label="Attribute 8 is greater than" operator="greaterThan" xlink:href="model.xml#at_8"/>
              </ber:itemArray>
            </ber:section>
          </ber:sectionArray>
        </ber:simpleLayout>
      </ber:tab>
    </ber:tabControl>
  </ber:filterForm>
</ber:filterFormArray>

filterFormArray - collection of all filter forms defined in the configuration for particular feature types
filterForm - definition of one filter form - configuration syntax is similar to standard light form
- id - mandatory unique id of the filter form
- name - mandatory name of the filter form displayed in the application
- usage - not used in filter forms - can be empty
- attributeFilter - component for editing one feature attribute condition in the filter form
  - label - optional component label displayed in the application - when not defined, label from model.xml attribute definition is used.
  Hint: Use labels in filter forms, because used filter operator is not displayed in the application, so it is good to have meaningful label for user including the operator.
  - xlink:href - mandatory reference to feature attribute in model.xml
  - operator - optional attribute defining operator used for filtering by this attribute. If not defined, default operator for particular attribute data type is used. Default operators and other possible values are described in previous chapters.

Horizontal Form Layouts

Each form contains "layout" components that define how the form is structured. There are several layout components available:

top level components tabControl, stepper, simpleLayout
inside components section, formItem

Note: formItem component is used in this chapter as an abstraction of all components that can be used in itemArray collection. It can be any component described in Form Components chapter.

Base top level component is simpleLayout. It represents form structure of one tab or step or whole form in case when there are no tabs or steps used. It contains collection of section components. Sections can be nested. Each section contains collection of inner sections OR collection of form items. By this possibilities various complex form structures can be created.

Sections and form items are by default displayed in vertical layout - one below another. It is possible to change this behaviour and display sections or form items in horizontal layout - side by side. This option will be available for both simpleLayout and section. If simpleLayout or section includes the attribute layout="horizontal", the application will try to place all directly contained form items/sections side by side. However, responsive design rules will always be respected — the application will automatically calculate the available space and fit as many form items/sections side by side as possible. Any remaining ones will wrap to the next line. So, even when horizontal layout is configured, it can happen that some components don't fit into one row on smaller screens and that they are arranged vertically.

Each form item has default minimal width defined in Form Components chapter. Application calculates minimal width of sections automatically depending on its content. This minimal width value can be overridden by minWidth attribute of the form item/section. By this attribute, it is possible to define how much space the form item/section needs at least to be displayed correctly. It can be less or more than default value.

When calculating form item/section sizes and layout, the application uses its own internal size units. Only the width of form items/sections will be considered — height does not affect layout calculations. The item's width will not be calculated based on its appearance or configuration. The size of application units in device pixels will vary depending on screen size and UI/font settings.

Form Definition​

Form​

Tab Control​

Stepper​

Simple Layout​

Section​

Form Components​

Feature Attribute Editor​

Feature attribute data type string​

Feature attribute data type number​

Feature attribute data type date / short date​

Feature attribute data type small codelist​

Feature attribute data type large codelist / hierarchical codelist​

Feature attribute data type checkboxed codelist​

Feature ref attribute​

Colored radio buttons​

List of Related Features​

relatedBrowse​

relations​

List of Features​

List of Attachments​

List of Details​

Protocols​

Business Workflow Actions​

Signature​

Static Text - annotations​

Toolbar​

LIDS Form​

Filter Form​

Feature attribute data type string​

Feature attribute data type number​

Feature attribute data type date / short date​

Feature attribute data type small codelist​

Feature attribute data type large codelist / hierarchical codelist​

Feature attribute data type checkboxed codelist​

Feature ref attribute​

Horizontal Form Layouts​

Form Definition

Form

Tab Control

Stepper

Simple Layout

Section

Form Components

Feature Attribute Editor

Feature attribute data type string

Feature attribute data type number

Feature attribute data type date / short date

Feature attribute data type small codelist

Feature attribute data type large codelist / hierarchical codelist

Feature attribute data type checkboxed codelist

Feature ref attribute

Colored radio buttons

List of Related Features

relatedBrowse

relations

List of Features

List of Attachments

List of Details

Protocols

Business Workflow Actions

Signature

Static Text - annotations

Toolbar

LIDS Form

Filter Form

Feature attribute data type string

Feature attribute data type number

Feature attribute data type date / short date

Feature attribute data type small codelist

Feature attribute data type large codelist / hierarchical codelist

Feature attribute data type checkboxed codelist

Feature ref attribute

Horizontal Form Layouts