> For the complete documentation index, see [llms.txt](https://docs.eximee.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/formularze/praca-z-komponentami-bazowymi/walidacja-wartosci-komponentow/walidacje-zlozone-wlasne.md). # Complex validations (custom) Complex validations requiring algorithm implementation are implemented by developers and added to the validator library located in **Eximee Validation**. In the case where validation is to be carried out through external services (e.g. ESB bus), it is necessary to use **Service Proxy** to make the given service available. If validations do not require connection to external services, you can use lightweight script validators (more in: [Script validators (validationScript)](/documentation/documentation-en/budowanie-aplikacji/logika-biznesowa/scriptcode/walidatory-skryptowe-validationscript.md)). Complex validators can be used for application fields, pages, or complex components (used later in the application). ### Complex validations for components In addition to requiredness and mask, specialized external validators can also be added to components. #### **Connecting a validator** To connect a validator, go into artifact edit mode and select any component that can have a validator connected. Then click the section **Data quality** in the component properties menu. After expanding the section, we will see the subsection **VALIDATORS**.

Figure 1. The "Data quality" section with the VALIDATORS subsection

After clicking on **VALIDATORS** or the pencil icon, the validators window will slide out.

Figure 2. Validators window

After selecting the option **Choose validator** we will be able to search for and select a given validator. The list contains standard validators and script validators. For a validator, you can define a call condition (field **Add condition**). This is a JavaScript condition in which you can use fields or session variables available in the application. The method of creating conditions is described in [Expression language for defining conditions (conditions from getValue)](/documentation/documentation-en/budowanie-aplikacji/logika-biznesowa/jezyk-wyrazen-definiowania-warunkow-warunki-z-getvalue.md).

Figure 3. Adding a validator

#### **Simulation** Validators, just like external services, support the option to replace their operation with a simulation script. Connecting such a script requires selecting the tab in the validators window **Simulation** and selecting an available simulation script from the list.

Figure 4. Simulation script connection tab

From this level, we can also choose to create a new script by clicking the button **Generate new script**. The newly created script will have content generated automatically, consistent with the validator and the described separate code sections.

Figure 5. Creating a simulation script

It should be remembered that such scripts will run **only** when entering the application with **enabled** application logic simulation mode! ### Complex validations on the page #### **Adding validators on the page** Validators can also be added on the page: * If the page listens to fields that we pass to the validator, the validator is called when the field that the page listens to changes. * If the page does not listen to fields, the validator will only be called after clicking the button **Next/Send.**\

Figure 6. Properties panel with two validators added for the Page1 page

#### **Adding** **validators on a complex component** It is possible to add validators on a complex component. They will work as if they were added on the page where the complex component is located. ### Adding translations of validation messages Each validator returns a validation message. The message content may already be translated into Polish or may be in another language. After connecting the validator, go to the tab **Translations** and search for the appropriate error key to change the translation. If the validator message contains parameters, then in the translation they should also be placed in the appropriate place.

Figure 7. Example of translating a message for a validator with parameter passing

{% hint style="info" %} More information in [Creating validators](/documentation/documentation-en/budowanie-aplikacji/logika-biznesowa/scriptcode/walidatory-skryptowe-validationscript/tworzenie-i-podpiecie-walidatorow-skryptowych.md). {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/formularze/praca-z-komponentami-bazowymi/walidacja-wartosci-komponentow/walidacje-zlozone-wlasne.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.