# Expression language
**Conditional expression language in Eximee** allows conditional logic to be defined (e.g. field visibility, activity, requiredness) using JavaScript syntax extended with specific methods. Conditions are written as expressions that the platform **Eximee** checks while the application is running. Below is described the syntax, available methods and attributes, as well as tools that make it easier to create and test conditions.
## Conditional expressions in Eximee
* **JavaScript in conditions:** All conditions in the application template can be described using JavaScript expressions. This means that in the condition field we can use standard operators (`==`, `!=`, `>`, `<`, `&&`, `||`, `!`) as well as JavaScript functions. The syntax allows, among other things, negation (`!condition`), conjunction (`condition1 && condition2`) and disjunction of conditions (`condition1 || condition2`).
* **Access to component values:** To retrieve current field values, use the function **`getValue("COMPONENT_ID")`**, where *COMPONENT\_ID* is the identifier of a field, session variable, or component in the form. [This is the recommended way to obtain a component value (other methods may cause performance issues). ](#user-content-fn-1)[^1]For example, calling `getValue("TextField1")` will return the current text entered in the text field with ID = TextField1.
* **Access to other attributes:** In addition to the value, components also have other properties that can be referenced. The function **`getData("COMPONENT_ID", "ATTRIBUTE")`**is used for this, returning the value of the specified component attribute. For example `getData("Checkbox1", "visible")` will return information about the visibility of the field **Checkbox1** (analogously to using `isVisible("Checkbox1")`). The list of available attributes for individual component types is shown in the component documentation and partly discussed in the next section.
* **Data types in conditions:** All values retrieved from fields are treated as text (strings) when the condition is evaluated. Therefore, for numeric or logical comparisons, you must convert data types yourself. You can use standard JavaScript functions such as `parseInt()` (conversion to an integer) or `parseFloat()` (conversion to a floating-point number). For boolean values, remember that the string `"true"`/`"false"` should be compared as a string or converted to a boolean type.
* **Constants:** In expressions, you can use text constants (enclosed in quotation marks), numeric constants (written directly), and logical constants (`true`/`false` without quotation marks).
* **Session variables in conditions:** If we want to use a session variable (global for the application) in a condition, we can reference it via `getValue("VARIABLE_NAME")`. In some cases (e.g. inside composite components), the variable name must be preceded by the `@`. For example, the expression `getValue("@variable1")=="Y"` will check whether the session variable `variable1` has the value "Y". Note: Predefined system variables (if present) may not require this prefix. However, it is recommended to use `@` before the names of your own variables in complex contexts to avoid ambiguity.
* **Complex conditions and dependencies:** You can build complex expressions by combining several comparisons with logical operators. E.g. the expression `getValue("Field1") != "" && parseInt(getValue("Field2")) > 100.` The expression will return `true` only if *Field1* is not empty **and at the same time** the numeric value *of Field2* is greater than 100. When defining conditions that depend on the values of other fields, **remember to define listening** — more on this later (the [**ListeningOn**](#user-content-fn-2)[^2]).
## Component attributes
Each form component has a set of standard attributes describing its state. The most important common attributes are:
* **`value`** – current *internal* value of the component (e.g. text entered into a field, a checkbox selection, the selected option in a list).
* **`displayValue`** – the value *displayed* to the user. It often matches `value`, but for some fields it may differ (e.g. in a Combobox `value` is the code/ID of the selected option, and `displayValue` is the label text).
* **`visible`** – information about the component's visibility (`"true"` or `"false"`). In conditions you can also use the function `isVisible("ID")` which serves a similar role.
* **`enabled`** – information about the component's activity (editability), taking the value `"true"` when the field is active or `"false"` when it is disabled (non-editable). This attribute determines whether the user can interact with the given field.
Other attributes may be specific to the component type. For example, a drop-down list component (Combobox) provides the attributes **`label`** (selected option text), **`description`** (additional description) or **`size`** (number of available options). The *Statements* component has a collection of items `statementsItemControl` representing individual declarations. A detailed list of attributes is available in the documentation for each component type.
| | |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Text field |
value displayValue visible
|
| Text area |
value displayValue visible
|
| Date |
value displayValue visible
|
| Date range |
value displayValue visible
|
| Plus minus |
value displayValue visible
|
| Formatted content (and collapsible) |
value displayValue visible
|
| Dropdown list field (Combobox) |
label - text of the selected value description - description of the selected value size - length of the value list
|
| Account selection |
value displayValue visible
|
| Checkbox |
moreInfoButtonClicked value displayValue visible
|
| Radio |
value displayValue visible
|
| Radio group |
value displayValue visible
|
| Tile group |
content - returns displayValue value displayValue visible
|
| Tile | visible |
| Statements |
statementsItemControl value displayValue visible
|
| Slider |
sliderValue value - (defaultValue) displayValue visible
|
| Step Slider |
sliderValue - value value - (defaultValue) displayValue visible
totalFilesSize fileNames externalIds value displayValue visible
|
| Data confirmation component |
wasEdited value displayValue visible
|
| QR code scanner |
value displayValue visible
|
| Map |
value displayValue visible
|
| Specialized component |
value displayValue visible
|
| Frontend component |
value displayValue visible
|
**Referencing attributes in conditions:** As mentioned, `getData(id, "attribute")`is used to read an attribute. However, in practice most conditions simply check the field value (`value`) or its visibility/activity. For convenience, the Eximee platform provides dedicated API methods:
* **`getValue("ID")`** – returns the `value` component value for the specified ID (most commonly used).
* **`isVisible("ID")`** – returns information about component visibility (string `"true"`/`"false"`).
*(Some special components have additional methods, e.g. for handling declaration groups – described below.)*
> *Example:* If the text field *EmailAddress* has the identifier `GesTextField5`, then:
>
> * `getValue("GesTextField5")` will return the entered email address,
> * `isVisible("GesTextField5")` will return `"true"` if the field is visible or `"false"` if it has been hidden.
**Special attributes – Declarations component:** For components of type *Statements* (list of consents/acceptances), functions are available that allow you to check whether a specific declaration has been selected. The method **`getStatementValue("COMPONENT_ID", "DECLARATION_MID")`** returns the value of the given declaration (consent) on that component. In newer versions, this function may be available under the name `getStatementItem`. Usage is as follows: e.g. `getStatementValue("Consents1", "newsletter") == "true"` will return `true`, if in the component with ID *Consents1,* the declaration with identifier (MID) *newsletter* is accepted by the user.
## Advanced condition editor
Eximee Designer provides **an advanced condition editor**, which makes it easier to create, edit, and verify conditional expressions. This editor has the following features:
* **Syntax highlighting:** the syntax of JavaScript expressions is highlighted with colors, which improves readability of complex conditions.
* **Auto suggestions:** while editing a condition, suggestions of available variables and form fields are displayed, as well as suggestions of Eximee API elements and frequently used JS methods.
* **Support for the prefix "`js:"`:** there is no need to manually type the prefix `"js:"` before the condition—the editor omits it in the view and automatically adds it in the source code when the condition is saved. This means the user enters only the actual expression, and the platform takes care of the correct format.
**Where the condition editor is used:** The advanced editor is used in component property fields such as: **visibility condition**, **activity (edit) condition** and **required condition**. These three properties of each form component use the editor described here and allow you to enter a formula deciding, respectively, whether the component is visible, active (enabled), and whether it is required to be filled in.
**Syntax hints in the editor:** In condition edit mode, you can use suggestions by pressing **Ctrl + Space**. This will display a list of available elements to use. Among the suggestions are, among others:
* *Standard JavaScript functions and properties:* `parseInt()`, `parseFloat()`, property `.length` (text length) or `size` (list size), as well as other commonly used constructs (e.g. the keyword `empty` for checking empty values).
* *Eximee API:* functions provided by the platform, such as `getValue()`, `getData()`, `isVisible()` or `getStatementValue()`, will appear in the suggestion list, reminding you of their availability.
* *Field and variable identifiers:* the editor automatically suggests **component MIDs** available in the given form (together with their technical ID in parentheses) and the names of session variables used in the application. This allows you to quickly insert a reference to a specific field without having to remember its exact identifier.
> **Tip:** If there are many fields, to quickly find the suggestion for a specific component in the list, start typing its name (MID) – the list will be filtered. Suggestions help avoid typos in IDs and allow you to learn the available functions.
## Examples of using conditional expressions
Below are several example conditional expressions together with a description of how they work. Each example shows a snippet of code used in the condition definition and an explanation:
* ```js
parseInt(getValue("GesTextField3")) > 5
```
– integer comparison: checks whether the numeric value entered in the text field `GesTextField3` is greater than 5.
* ```js
parseFloat(getValue("GesTextField5")) < 200.001
```
– floating-point comparison: checks whether the value from the text field `GesTextField5` (e.g. an amount or a number with decimal places) is less than 200.001.
* ```js
getValue("GesCheckbox1") == "true"
```
– logical comparison (equality): checks whether the field of type *Checkbox* with ID `GesCheckbox1` is checked (has the value `"true"`).
* ```js
getValue("GesCheckbox1") != "true"
```
– logical comparison (inequality): checks whether this same checkbox **does not** is checked (i.e. the value is different from `"true"` – in practice `"false"` or no value).
* ```js
getValue("GesRadioGroup1") == "audi"
```
– text comparison: checks whether in the Radio button group with ID `GesRadioGroup1` the option with value `"audi"` has been selected (e.g. one of the car brands).
* ```js
!!getValue("nazwiskoZew")
```
– double negation: checks whether a given value is not empty. Two exclamation marks convert the value to boolean – the expression will return `true`, if the variable or field `surnameExternal` has a non-empty value (e.g. the user entered a surname), and `false` otherwise.
* ```js
!getValue("nazwiskoZew")
```
– negation: checks whether the value is empty. It will return `true`, if the field/variable `surnameExternal` **has no value** (e.g. the user did not enter anything), which in JavaScript is equivalent to the value *falsy* (e.g. empty string `""`).
* ```js
getStatementItem("GesStatementPopup1", "declaration1") == "true"
```
– condition for a component of type *Statements*: checks whether the declaration with identifier (MID) `GesStatementPopup1` was selected in the component with ID `declaration1` (i.e. whether the user accepted this declaration).
* ```js
getStatementItem("@GesStatementFlat5", "health") == "false"
```
– a similar condition for *Statements* inside a composite component: checks whether the declaration `health` in the component with ID `GesStatementFlat5` (embedded in a composite component, hence the prefix `@`) **has not been** selected by the user.
* ```js
!!!(getValue("@GesTextField13") || getValue("@GesTextField8"))
```
– example of a requiredness condition: triple negation before the expression in parentheses checks whether *both* text fields `GesTextField13` and `GesTextField8` are empty. Inside the parentheses, the operator `||` returns the first non-empty value (or an empty one if both values are empty). Applying `!` inverts the result, and `!!` converts it to boolean. The overall effect is `true` only if **both fields are empty** (then, for example, another field becomes required). If either field has a value, the expression will return `false` (i.e. the requiredness condition is not met, so, for example, a given field does not have to be required).
* ```js
getValue("@GesCombobox1") != 2 && getValue("@GesCombobox1") > 0
```
– complex condition for a drop-down list (Combobox): checks two things at once – whether the value selected in the Combobox field `GesCombobox1` **is not equal to 2** and whether it is **greater than 0**. Such a condition could be used, for example, to verify a selection other than the default one (assuming that value `0` means no selection, and `2` is some excluded option).
* ```js
isVisible("@GesTextField1") == "true"
```
– visibility state check: the condition will return `true`, if the component with ID `GesTextField1` is currently visible (e.g. another condition has not hidden it). This can be used to make behavior depend on whether another field is on the screen.
* ```js
getValue("GesTextField5").length == 10
```
– text length check: the condition returns `true`, if exactly 10 characters have been entered into the text field `GesTextField5` . This can be used, for example, for format validation (checking whether a number has the required length).
*(In the examples above, sample identifiers generated by the system were used, such as **GesTextField5**. In a real project, it is recommended to give fields readable business identifiers (MID), which makes it easier to refer to them later in conditions)*
### Conditional expressions in composite and business components
* Inside a composite/business component, to explicitly indicate a variable/field from that component, precede the name with the `@`:
* `getValue("@variableName")`
* Example: `getValue("@defaultCurrency") == "USD"`.
* Why? during condition evaluation `@` expands to the component identifier, e.g. `getValue("@variableName")` → `getValue("GesComplexComponent1.variableName")`, which eliminates name collisions with the main form on which the component is placed.
* When there is a name collision (the same variable/field in the main application and in the component) or you want to be precise — use `@` even if the condition works without it.
* Good practice: in composite/business components always precede the names of variables/fields with the `@` in conditional expressions, unless you deliberately want to refer to a variable/field from the main form - then omit `@`
* Note: system predefined variables are placed on the main form, so we refer to them directly by name, omitting the character `@`.
Examples:
* Main form: `getValue("defaultCurrency") == "USD"`.
* Inside the component (precisely to the variable from this component): `getValue("@defaultCurrency") == "USD"`.
## FAQ – Frequently asked questions
**How do I set a component to be displayed conditionally (e.g. after checking a checkbox)?**\
You should use the property **Visibility condition (visibleCondition)** available in the component properties panel. In the condition field, enter an expression that should return `true` when the component is to be visible. For example: if the field *AdditionalSection* is to be shown after checking the checkbox *ShowSections (id=GesCheckbox7)*, set the visibility condition: `getValue("GesCheckbox7") == "true"`. When the user checks the given checkbox, the condition will be met and *AdditionalSection* will become visible.
**The condition does not refresh after changing another field – what am I doing wrong?**\
You probably have not set **listening**. For a component to react to changes in the value of another field used in the expression, you need to set the attribute **ListeningOn** (Listening) for that field. In other words, the component with the condition must "listen" to the component on which the condition depends. In Eximee Designer you do this in the **Interactions** component properties section – add the dependent field identifier to the Listening list. After listening is set correctly, changing the value of one field will automatically cause the condition in the other field to be re-evaluated.
**How do I check in a condition whether a field is empty or filled in?**\
This can be done in several ways. The simplest is to use the fact that an empty string in JavaScript is a *falsy* (falsy) value. For example: the expression `!getValue("FieldX")` will return `true`, when *FieldX* is empty (negation of an empty string gives true). Conversely, the expression `!!getValue("FieldX")` will return `true`, only if *FieldX* has some value (double negation converts the value to boolean while preserving its "truthiness"). Alternatively, you can compare directly to an empty string: `getValue("FieldX") == ""` (empty) or `getValue("FieldX") != ""` (filled in).
**Do I need to add the prefix `js:`?**\
No. In the Eximee Designer editor, you enter only the condition expression itself, without any prefixes. The prefix `"js:"` is added automatically in the source code and is used internally to indicate that the condition should be interpreted as a JavaScript script. If you inspect the application's XML configuration, you will see `condition="js:...your_expression..."`, but in the Designer interface you do not need (and should not) type this yourself.
**How do I define a condition that is always met (always true)?**\
If we want a given action/condition to be *always* true (e.g. so that an element is always visible or some action always runs), we can enter a true constant as the expression. In practice, it is enough to enter the value **`true`**. The editor will add the appropriate prefix and the condition will be treated as always satisfied. Alternatively, you can enter **`js:true`** in the raw configuration – the effect will be the same. Similarly, an always-false condition can be obtained by entering `false` (which will make, for example, a given component never visible on its own).
**Can I use any JavaScript functions in conditions?**\
Basic JavaScript functions and operators are supported, especially those suggested by the editor (such as `parseInt`, `parseFloat`, logical operators, etc.). However, remember that the condition is executed in the user's browser context, so it should not contain calls that may be incomprehensible or unavailable. A good practice is to limit yourself to simple operations and use the API provided by the Eximee platform (e.g. `getValue`, `getData`, etc.) for consistency and performance. Direct references to DOM elements or global variables are not supported and may cause errors. If you need complex logic, consider placing it in validator or service code.
[^1]: I would probably not point readers toward other methods, especially since they can cause performance issues.
[^2]: would be useful here as a link
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/formularze/dynamicznosc-formularza/jezyk-wyrazen.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.