# Common component properties

## Basic component properties <a href="#wspolnewlasciwoscikomponentow-podstawowewlasnoscikomponentow" id="wspolnewlasciwoscikomponentow-podstawowewlasnoscikomponentow"></a>

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

<table><thead><tr><th width="224.5390625">Eximee Designer property</th><th width="253.6953125">Attribute name in the Source</th><th>Description</th></tr></thead><tbody><tr><td>A section <strong>Basic properties</strong></td><td></td><td></td></tr><tr><td><strong>Id</strong></td><td>id</td><td>Unique technical field identifier (assigned automatically when adding a component).</td></tr><tr><td><strong>Business identifier</strong></td><td>mid</td><td><p>Business field identifier (by default it is the same as the id, but it can be changed).<br><br>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. Components of type Label (Text) and Formatted Content (TextContent) do not have a Mid.</p><p>The business identifier should be written in camelCase, it should not contain spaces or Polish characters.<br><br><strong>NOTE!</strong></p><p>Since the Uniflow data model is based on business field identifiers (mid) rather than ids, when using the Uniflow data model in an application, business field identifiers must not repeat (e.g. we have two different components with the same business identifier, or a component has the same mid as a session variable id).<br></p></td></tr><tr><td><strong>Label</strong></td><td>label</td><td><p>Component label displayed above the component (the attribute is not supported in some channels).</p><p><br></p></td></tr><tr><td><strong>Inactive field displayed as a label</strong></td><td>labelIfDisabled</td><td><p>Checked (set to "true") means that an inactive component is displayed as text (in the application it looks like it is displayed as a label).</p><p>The availability of the functionality depends on the license and may not be available in all deployments.</p><p>Demo application: demoLabelIfDisabled</p></td></tr><tr><td><strong>Contextual help</strong></td><td>toolTips</td><td><p>Defining dynamic contextual help for a component depending on conditions.</p><p>More at: <a href="pomoc-kontekstowa">Contextual help - Tooltip</a></p></td></tr><tr><td><strong>Data model key</strong></td><td>model</td><td><p>For fields that can take values, it defines a two-way binding with the data model.</p><p>More at: <a href="../../../model-danych/przechowywanie-danych-w-modelu">Storing data in the model</a></p></td></tr><tr><td>A section <strong>Data quality</strong></td><td></td><td></td></tr><tr><td><strong>Visibility condition</strong></td><td>visibleCondition</td><td>Field visibility condition (conditions are entered using the editor described in <a href="../../../logika-biznesowa/jezyk-wyrazen-definiowania-warunkow-warunki-z-getvalue/zaawansowany-edytor-warunkow">Advanced condition editor</a>).</td></tr><tr><td><strong>Activity condition</strong></td><td>enabledCondition</td><td>Field editability condition (conditions are entered using the editor described in <a href="../../../logika-biznesowa/jezyk-wyrazen-definiowania-warunkow-warunki-z-getvalue/zaawansowany-edytor-warunkow">Advanced condition editor</a>).</td></tr><tr><td><strong>Maximum value length</strong></td><td>maxPropertyLength</td><td><p>For security reasons, every text value in the platform (e.g. text field content, dropdown value and description, radio value, etc.) is verified for length. By default, the platform does not allow strings longer than 256 characters. If, due to business requirements, it is necessary to change the maximum length, it can be done using the attribute <strong>Maximum value length</strong>.<br>The availability of this functionality depends on the license and may not be available in all deployments.</p><p><strong>NOTE!</strong></p><p>The system has an additional hard limit (default: 10485760 characters) - this is an absolute limit that will not be overridden by the Maximum value length attribute.<br></p></td></tr><tr><td><strong>Requirement condition</strong></td><td>requiredCondition</td><td>Field requirement condition (conditions are entered using the editor described in <a href="../../../logika-biznesowa/jezyk-wyrazen-definiowania-warunkow-warunki-z-getvalue/zaawansowany-edytor-warunkow">Advanced condition editor</a>).</td></tr><tr><td><strong>Validators</strong></td><td>externalValidators</td><td><p>Defining specialized external validators.</p><p>More at: <a href="walidacja-wartosci-komponentow/walidacje-zlozone-wlasne">Complex validations</a></p></td></tr><tr><td><strong>Default value</strong></td><td>defaultValue</td><td>For fields that can take values, it defines the component's initial value.</td></tr><tr><td><strong>Formatter</strong></td><td>formatter</td><td>See: <a href="../../../logika-biznesowa/scriptcode/formatery">Setting formatting for a component</a>.</td></tr><tr><td>A section <strong>Interactions</strong></td><td></td><td></td></tr><tr><td><strong>Listening</strong></td><td>listeningOn</td><td><p>A list of components on which the component depends. Changing the values of listened-to components will refresh the component state.</p><p>More at: <a href="../dynamicznosc-formularza/nasluchiwanie-i-czyszczenie">Listening and clearing</a>.</p></td></tr><tr><td><strong>External data source</strong></td><td>enternalDataSource</td><td><p>Defining external data sources.</p><p>More at: <a href="zasilanie-wartosciami-z-zewnetrznych-zrodel">Feeding components with external data sources</a></p></td></tr><tr><td><strong>Clearing a field</strong></td><td>clearOn</td><td>A list of components on which clearing the data entered into the component depends.</td></tr><tr><td><strong>Data source from another field</strong></td><td>valueSourceId</td><td>ID of another component that will provide the value for the given component (an example of use is described in: <a href="../../../logika-biznesowa/przekazywanie-wartosci-miedzy-komponentami-lub-stronami-wniosku">Passing values between components or application pages</a>).</td></tr><tr><td>A section <strong>Security</strong></td><td></td><td></td></tr><tr><td><strong>Whitelist of characters</strong></td><td>extraWhitelistCharacters</td><td><p>For security reasons, every text value in the platform (e.g. text field content, dropdown value and description, radio value, tile group value, etc.) is verified for allowed characters. By default, the platform allows the following character classes:</p><ul><li>letters (including diacritical characters of all languages),</li><li>digits,</li><li>whitespace characters (various types of spaces, tabs, newline markers, etc.),</li><li>the following special characters: '.' (period), ',' (comma), '-' (dash), '_' (underscore).</li></ul><p>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, you can use the attribute <strong>Whitelist of characters</strong> (extraWhitelistCharacters). The attribute value is a string of characters that are allowed in the given field.</p><p><strong>NOTE!</strong></p><p>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.</p><p>The @ character (at sign) is disallowed by default unless the field is of type "email" (parameter <strong>Data type</strong> (expected type)).</p><p><strong>IMPORTANT!</strong></p><p>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 <strong>Whitelist of characters</strong> both values - we define this for the Tile group, not for a single Tile.</p><p>Example: e.g. for a tile with the label "5+", the option value ">5" has been defined - in such a situation, in the whitelist we must define both "+" and ">" as allowed characters</p><p>(using different values for content and value is not a recommended solution; consistent values are recommended).</p></td></tr><tr><td><strong>Technical field</strong></td><td>technicalField</td><td>A field used for internal needs of the application template logic, it is not propagated to downstream systems and is not visible in the application. The property is available for selected components.</td></tr><tr><td>A section <strong>Styling</strong></td><td></td><td></td></tr><tr><td><strong>Style name</strong></td><td>styleName</td><td>The name of the component style (in eximee Webforms it corresponds to the CSS style assigned to a given component).</td></tr><tr><td>A section <strong>Other</strong></td><td></td><td></td></tr><tr><td><strong>Automatic value update</strong><br></td><td>autoServerUpdate</td><td><p>Automatic sending of the value to the server (regardless of whether anything listens to a given component). Additionally, when this flag is selected, graph processing (after the value changes) starts from the component whose value changed (by default, processing starts from its successors).</p><p><strong>NOTE!</strong></p><p>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.</p><p>Sample application with suggester and autoServerUpdate property: test_autoserverUpdate.</p></td></tr><tr><td><strong>GTM tag / Enabling GTM</strong></td><td>gtmTagName/pushTagsToGtm</td><td>Ability to configure the functionality <strong>Google Tag Manager</strong>. By default the field is not checked (value "false").</td></tr><tr><td><strong>Collecting statistics</strong></td><td>getStats</td><td>A field used to collect statistics about a given component. By default the field is not checked (value "false").</td></tr><tr><td><strong>Visibility on printout</strong></td><td>printable</td><td>Specifies whether the component should be visible on the application printout. By default the field is checked (value "true").</td></tr><tr><td><strong>Behavior of value changes when the component is hidden</strong></td><td>preserveValueWhenHidden</td><td><p>This flag is used to prevent the component value from being changed to the default when it is hidden (or hidden after unparking). The component value will also be preserved after parking and will be available for use in subsequent sessions. By default the field is not checked (value "false").</p><p>The functionality is not available for some components.</p></td></tr></tbody></table>

### Visibility conditions <a href="#wspolnewlasciwoscikomponentow-warunkiwidocznosci" id="wspolnewlasciwoscikomponentow-warunkiwidocznosci"></a>

For each component in the panel **Properties** you can define 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](https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/logika-biznesowa/jezyk-wyrazen-definiowania-warunkow-warunki-z-getvalue/zaawansowany-edytor-warunkow)). The expression language used is described in [Conditional expression language](https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/logika-biznesowa/jezyk-wyrazen-definiowania-warunkow-warunki-z-getvalue).

<figure><img src="https://2112972046-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2CssJT0zIo4SJQLbSZ6l%2Fuploads%2FB7edqhceX2RMunaHRX7g%2Fimage.png?alt=media&#x26;token=1d945d15-6e65-497c-85b3-c43714b32124" alt=""><figcaption><p><em><strong>Figure 1.</strong> Empty property for defining the visibility condition</em></p></figcaption></figure>

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

### Requirement conditions <a href="#wspolnewlasciwoscikomponentow-warunkiwymagalnosci" id="wspolnewlasciwoscikomponentow-warunkiwymagalnosci"></a>

For each component in the panel **Properties** you can define 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. The JavaScript language described in [Conditional expression language](https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/logika-biznesowa/jezyk-wyrazen-definiowania-warunkow-warunki-z-getvalue).

Components whose 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 <a href="#wspolnewlasciwoscikomponentow-warunkikomponentowwtrybietylkodoodczytu" id="wspolnewlasciwoscikomponentow-warunkikomponentowwtrybietylkodoodczytu"></a>

For each component in the panel **Properties** you can define 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. The JavaScript language described in [Conditional expression language](https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/logika-biznesowa/jezyk-wyrazen-definiowania-warunkow-warunki-z-getvalue).

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

### Listening <a href="#wspolnewlasciwoscikomponentow-nasluchiwanie" id="wspolnewlasciwoscikomponentow-nasluchiwanie"></a>

For each component, you can define a list of components that the given component listens to (more in [Listening and clearing](https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/formularze/dynamicznosc-formularza/nasluchiwanie-i-czyszczenie)).

A dependency graph is created based on listening. When the state of a component 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>
```

{% hint style="info" %}
Demo application: demoWspolneWlasciwosciKomponentow
{% endhint %}