Common component properties

Basic properties of components

Regardless of the type, each component has defined properties available in the panel displayed on the right side after selecting the component.

Eximee Designer property	Attribute name in the Source	Description
A section Basic properties
Id	id	Unique technical identifier of the field (assigned automatically when adding the component).
Business identifier	mid	Business identifier of the field (by default it is the same as the id, but it can be changed). The business identifier (Mid) is a unique identifier linked to business logic. Once assigned, it will be easier for us to find a specific component when adding listeners or Page Services input and output parameters. Text (Text) and Formatted content (TextContent) components do not have a Mid. The business identifier should be written in camelCase and should not contain spaces or Polish characters. NOTE! Since the Uniflow data model is based on business field identifiers (mid) and not on id, when using the Uniflow data model in an application, business field identifiers cannot be repeated (e.g. we have two different components with the same business identifier, or a component has the same mid as the session variable id).
Label	label	Component label displayed above the component (the attribute is not supported in some channels).
Inactive field displayed as a label	labelIfDisabled	Selected (set to "true") means that the inactive component is displayed as text (in the application it appears as displayed as a label). Availability of functionality depends on the license and may not be available in all deployments. Demo application: demoLabelIfDisabled
Context help	toolTips	Defining dynamic context help for a component depending on conditions. More in: Context help - Tooltip
Data model key	model	For fields that can accept values, it defines a two-way binding with the data model. More in: Storing data in the model
A section Data quality
Visibility condition	visibleCondition	Field visibility condition (conditions are entered using the editor described in Advanced condition editor).
Activity condition	enabledCondition	Field editability condition (conditions are entered using the editor described in Advanced condition editor).
Maximum value length	maxPropertyLength	For security reasons, every text value on the platform (e.g. text field content, dropdown value and description, radio value, etc.) is checked for length. By default, the platform does not allow strings longer than 256 characters. If business requirements require changing the maximum length, this can be done using the attribute Maximum value length. The availability of the functionality depends on the license and may not be available in all deployments. NOTE! The system also has an additional hard limit (default: 10485760 characters) - this is an absolute limit that will not be overridden by the Maximum value length attribute value.
Requirement condition	requiredCondition	Field requirement condition (conditions are entered using the editor described in Advanced condition editor).
Validators	externalValidators	Defining specialized external validators. More in: Complex validations
Default value	defaultValue	For fields that can accept values, it defines the component's initial value.
Formatter	formatter	See: Setting formatting for the component.
Field description	description	Text displayed as the field description below it, by default it is empty. The availability of the functionality depends on the license and may not be available in all deployments.
A section Interactions
Listening	listeningOn	List of components on which the component depends. Changing the values of listened-to components will refresh the component state. More in: Listening and clearing.
External data source	enternalDataSource	Defining external data sources. More in: Feeding components with external data sources
Clearing the field	clearOn	List of components on which clearing the data entered into the component depends.
Data source from another field	valueSourceId	ID of another component that will provide the value for the given component (an usage example is described in: Passing values between components or application pages).
A section Security
Whitelist of characters	extraWhitelistCharacters	For security reasons, every text value on the platform (e.g. text field content, dropdown value and description, radio value, tile group value, etc.) is checked for allowed characters. By default, the platform allows the following character classes: letters (including diacritical characters of all languages), digits, whitespace characters (various kinds of spaces, tabs, newline characters, etc.), the following special characters: '.' (period), ',' (comma), '-' (hyphen), '_' (underscore). If a value with a character outside the list reaches the server, the server will restore the last safe value. If, due to business requirements, it is necessary to extend the list of special characters for a given field, this can be done using the attribute Whitelist of characters (extraWhitelistCharacters). The attribute value is a string of characters that should be allowed in the given field. NOTE! When extending the list of allowed characters, for security reasons you should make sure that the services to which this value will be sent are ready to accept the given character and are properly secured. The @ character is not allowed by default unless the field type is "email" (parameter Data type (expected type)). IMPORTANT! For components that, in addition to a label, also have a value (e.g. Radio group, Tile group), and these values are different for some reason (in the context of disallowed characters), it is necessary to define in Whitelist of characters both values - we define this for the Tile group, not for an individual Tile. Example: for a tile with the label "5+", the option value is defined as ">5" - in such a case, in the whitelist we must define both "+" and ">" as allowed characters (using different values for content and value is not a recommended solution; it is recommended to use consistent values).
Technical field	technicalField	A field used for the internal needs of the application template logic, it is not propagated to subsequent systems and is not visible in the application. The property is available for selected components.
A section Styling
Style name	styleName	Name of the component style (in eximee Webforms it corresponds to the CSS style that will be assigned to the given component).
A section Other
Automatic value update	autoServerUpdate	Automatic sending of the value back to the server (regardless of whether anything listens to a given component). Additionally, when this flag is selected, processing in the graph (after a value change) starts from the component whose value changed (by default, processing starts from its successors). NOTE! This setting has a major impact on the performance of the application platform. It should be used only where required (e.g. when using the Suggester). In doubtful situations, please contact the Consdata team. Example application with a suggester and the autoServerUpdate property: test_autoserverUpdate.
GTM tag / Enable GTM	gtmTagName/pushTagsToGtm	Ability to configure the functionality Google Tag Manager. By default the field is not selected (value "false").
Collecting statistics	getStats	Field used to collect statistics about a given component. By default the field is not selected (value "false").
Visibility in printouts	printable	Specifies whether the component should be visible in the application printout. By default the field is selected (value "true").
Behavior of value change when the component is hidden	preserveValueWhenHidden	This flag is used to prevent the component value from being changed to the default when it is hidden (or hidden after being unparked). The component value will also be preserved after parking and will be available for use in subsequent sessions. By default the field is not selected (value "false"). The functionality is not available for some components.

Visibility conditions

For each component in the panel Properties you can specify its visibility conditions by clicking Add visibility condition in the field VISIBILITY CONDITION (available in the section Data quality). In the displayed condition editor, you can enter conditions written in a simple expression language (more in Advanced condition editor). The expression language used is described in Condition definition expression language.

Figure 1. Empty property for defining a visibility condition

The component is visible only if the condition entered in the field is met VISIBILITY CONDITION.

Requirement conditions

For each component in the panel Properties you can specify the conditions under which the component is required by clicking Add requirement condition in the field REQUIREMENT CONDITION (available in the section Data quality). The condition editing window is analogous to the component visibility condition editing window. JavaScript language described in is used to define conditions Condition definition expression language.

Components for which the condition is met are required and it is not possible to proceed to the next page of the application without entering a value.

Component conditions in read-only mode

For each component in the panel Properties you can specify the conditions under which the component is displayed in read-only mode by clicking Add activity condition in the field ACTIVITY CONDITION. The condition editing window is analogous to the component visibility condition editing window. JavaScript language described in is used to define conditions Condition definition expression language.

For components with an unmet condition, editing their values is blocked during application display.

Listening

For each component, you can define a list of components that a given component listens to (more in Listening and clearing).

A dependency graph is created based on listening. When a component's state changes, the dependency subgraph containing all paths ending at the changed component is topologically sorted and the components in the subgraph are refreshed. Components are refreshed in the order resulting from the topological sort in such a way that only those components are refreshed whose at least one direct predecessor in the graph has changed state.

Cycles in the dependency graph are resolved arbitrarily (cut off after the component located deeper in the graph)

It is possible to enable refreshing of all components in the graph (regardless of whether the direct predecessor changed state). This is an administrative action and requires changing the following entry in the /etc/eximee/webforms.xml file:

<webforms>
    <server>
        ...
        <nonBlockingGraphFormTemplates>template_name1,template_name2</nonBlockingGraphFormTemplates>
    </server>
</webforms>

Demo application: demoWspolneWlasciwosciKomponentow