Expression language

The language of conditional expressions in Eximee allows defining conditional logic (e.g. field visibility, activity, requiredness) using JavaScript syntax extended with specific methods. Conditions are written as expressions that the platform Eximee checks during application runtime. Below is a description of the syntax, available methods and attributes, as well as tools that make creating and testing conditions easier.

Conditional expressions in Eximee

• JavaScript in conditions: All conditions in the application template can be described with JavaScript expressions. This means that in the condition field we can use standard operators (==, !=, >, <, &&, ||, !) and JavaScript functions. The syntax allows defining, among others, negation (!condition), conjunction (condition1 && condition2) and condition alternatives (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's value (other methods may cause performance issues). For example, calling getValue("PoleTekst1") will return the current text entered in the text field with ID = PoleTekst1.
• Access to other attributes: Besides the value, components also have other properties that can be referenced. For this, use the function getData("COMPONENT_ID", "ATTRIBUTE"), which returns the value of the given component attribute. For example getData("Checkbox1", "visible") will return information about the visibility of the field Checkbox1 (similarly 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 (string) when evaluating the condition. Therefore, for numeric or logical comparisons, you need to 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: Expressions can use text constants (enclosed in quotes), numeric constants (written directly), and boolean constants (true/false without quotes).
• Session variables in conditions: If you want to use a session variable (global for the application) in a condition, you can reference it via getValue("NAZWA_ZMIENNEJ"). In some cases (e.g. inside composite components) you need to prefix the variable name with @. For example, the expression getValue("@zmienna1")=="Y" will check whether the session variable zmienna1 has the value "Y". Note: predefined system variables (if any) may not require this prefix. However, it is recommended to use @ before custom variable names in complex contexts to avoid ambiguity.
• Complex conditions and dependencies: You can build complex expressions by combining several comparisons with logical operators. For example, the expression getValue("Pole1") != "" && parseInt(getValue("Pole2")) > 100. The expression will return true only if Pole1 is not empty and at the same time the numeric value of Pole2 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).

Component attributes

Each form component has a set of standard attributes describing its state. The most important common attributes are:

• value – current internal component value (e.g. text entered in the field, checkbox selection, selected list option).
• 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), takes 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 a given field.

Other attributes may be specific to the component type. For example, the drop-down list component (Combobox) provides attributes label (selected option text), description (additional description) or size (number of available options). The component Statements has a collection of items statementsItemControl representing individual statements. 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
Value selection from list (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
Dual-range slider	value displayValue visible
A section	folded
Checkbox section	value displayValue visible
Repeatable section	folded
Context help	value displayValue visible
Product selection	variantId productId value displayValue visible
Picture card	value displayValue visible
Attachments	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, the attribute is read using getData(id, "attribute"). However, in practice most conditions simply check the field value (value) or its visibility/activity. For convenience, Eximee provides dedicated API methods:

• getValue("ID") – returns the value component with the specified ID (most commonly used).
• isVisible("ID") – returns information about the component's visibility (string "true"/"false").

(Some special components have additional methods, e.g. for handling statement groups – described later.)

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 – Statements component: For components of type Statements (list of consents/approvals) there are functions that allow checking whether a specific statement has been selected. The method getStatementValue("COMPONENT_ID", "STATEMENT_MID") returns the value of the given statement (consent) on this component. In newer versions this function may be available under the name getStatementItem. Usage is as follows: e.g. getStatementValue("Zgody1", "newsletter") == "true" will return true, if in the component with ID Zgody1, the statement with identifier (MID) newsletter has been accepted by the user.

Advanced condition editor

Eximee Designer provides an advanced conditions editor, which makes creating, editing, and validating conditional expressions easier. This editor includes the following features:

• Syntax highlighting: the syntax of JavaScript expressions is color-highlighted, which increases the readability of complex conditions.
• Auto-complete: while editing a condition, hints for available variables and form fields are displayed, as well as hints for Eximee API elements and commonly used JS methods.
• Support for the prefix "js:": there is no need to manually type the prefix before the condition "js:" — the editor omits it in the view and automatically adds it in the source code when the condition is saved. As a result, the user enters only the actual expression, and the platform takes care of the correct format.

Where the conditions editor is used: The advanced editor is used in component property fields such as: visibility condition, activity condition (editing) and requiredness condition. These three properties of each form component use the described editor and allow entering a formula that determines whether the component is visible, active (unlocked), and whether it is required to be filled in.

Syntax hints in the editor: In condition edit mode, you can use hints by pressing the keys Ctrl + Space. This will display a list of available elements to use. Among the hints are:

• Standard JavaScript functions and properties: parseInt(), parseFloat(), the 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 hints list, reminding you of their availability.
• Field and variable identifiers: the editor automatically suggests component MIDs available in a given form (along with their technical ID in parentheses) and the names of session variables used in the application. This lets you 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 hint for a specific component in the list, start typing its name (MID) — the list will be filtered. Hints help avoid typos in IDs and let you learn about available functions.

Examples of using conditional expressions

Below are a few example conditional expressions along with descriptions of what they do. Each example shows a snippet of code used in the condition definition and an explanation:

• parseInt(getValue("GesTextField3")) > 5

  – integer comparison: checks whether the numeric value entered in text field GesTextField3 is greater than 5.
• parseFloat(getValue("GesTextField5")) < 200.001

  – floating-point comparison: checks whether the value from text field GesTextField5 (e.g. amount or number with decimals) is less than 200.001.
• getValue("GesCheckbox1") == "true"

  – logical comparison (equality): checks whether the field of type Checkbox with ID GesCheckbox1 is selected (has value "true").
• getValue("GesCheckbox1") != "true"

  – logical comparison (inequality): checks whether the same checkbox no is selected (i.e. has a value different from "true" – in practice "false" or has no value).
• 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).
• !!getValue("nazwiskoZew")

  – double negation: checks whether a given value is not empty. Two exclamation marks convert the value to a boolean type – the expression will return true, if the variable or field nazwiskoZew has a non-empty value (e.g. the user entered a surname), and false otherwise.
• !getValue("nazwiskoZew")

  – negation: checks whether the value is empty. It will return true, if the field/variable nazwiskoZew has no value (e.g. the user entered nothing), which in JavaScript is equivalent to the value falsy (e.g. empty string "").
• getStatementItem("GesStatementPopup1", "oswiadczenie1") == "true"

  – condition for component type Statements: checks whether in the component with ID GesStatementPopup1 the statement with identifier (MID) oswiadczenie1 has been selected by the user (i.e. whether the user accepted this statement).
• getStatementItem("@GesStatementFlat5", "zdrowotne") == "false"

  – similar condition for Statements inside a composite component: checks whether the statement zdrowotne in the component with ID GesStatementFlat5 (embedded in a composite component, hence the prefix @) has not been selected by the user.
• !!!(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 empty, if both values are empty). Applying ! reverses the result, and !! converts it to a boolean. The overall effect is that true only if both fields are empty (then, for example, another field becomes required). When either field has a value, the expression will return false (meaning the requiredness condition is not met, so e.g. the given field does not have to be required).
• getValue("@GesCombobox1") != 2 && getValue("@GesCombobox1") > 0

  – a complex condition for a 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 choice other than the default one (assuming that the value 0 means no selection, and 2 is some excluded option).
• 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 an action depend on whether another field is on the screen.
• getValue("GesTextField5").length == 10

  – text length check: the condition returns true, if exactly 10 characters were entered in 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 (MIDs), which makes it easier to refer to them later in conditions)

Conditional expressions in composite and business components

• Inside a composite/business component, to unambiguously indicate a variable/field from that component, prefix the name with @:

  • getValue("@variableName")
  • Example: getValue("@defaultCurrency") == "USD".
  • Why? During condition evaluation @ it 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.
• If 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 prefix variable/field names with @ in conditional expressions, unless you intentionally want to reference 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 sign @.

Examples:

• Main form: getValue("walutaDomyślna") == "USD".
• Inside the component (specifically to the variable from this component): getValue("@defaultCurrency") == "USD".

FAQ – Frequently Asked Questions

How do I set a component to display conditionally (e.g. after selecting a checkbox)? You need to 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 selecting checkbox ShowSections (id=GesCheckbox7), then 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 another field changes — what am I doing wrong? You are probably missing the setting listening. For the component to react to changes in another field value used in the expression, you need to set its ListeningOn (Listening) attribute to point to 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's identifier to the Listening list. Once listening is set correctly, changing one field's value will automatically re-evaluate the condition in the other field.

How do I check in a condition whether a field is empty or filled? This can be done in several ways. The simplest is to use the fact that an empty string in JavaScript is a falsy (falsy). For example: the expression !getValue("PoleX") will return true, when PoleX is empty (negating an empty string gives true). Conversely, the expression !!getValue("PoleX") will return true, only if PoleX has some value (double negation converts the value to boolean while preserving its "truthiness"). Alternatively, you can compare directly to the empty string: getValue("PoleX") == "" (empty) or getValue("PoleX") != "" (filled).

Do I need to add the prefix js:? No. In the Eximee Designer editor, we 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 to (and should not) type it 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 an action is always performed), 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 cause, for example, that a given component will never be 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 context of the user's browser, 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. Directly referencing DOM elements or global variables is not supported and may cause errors. If you need complex logic, consider placing it in the validator or service code.