# Wspólne właściwości komponentów

## Podstawowe własności komponentów <a href="#wspolnewlasciwoscikomponentow-podstawowewlasnoscikomponentow" id="wspolnewlasciwoscikomponentow-podstawowewlasnoscikomponentow"></a>

Niezależnie od typu każdy komponent posiada zdefiniowane właściwości dostępne w panelu wyświetlonym z prawej strony po zaznaczeniu komponentu.

<table><thead><tr><th width="224.5390625">Właściwość Eximee Designer</th><th width="253.6953125">Nazwa atrybutu w Źródle</th><th>Opis</th></tr></thead><tbody><tr><td>Sekcja <strong>Podstawowe właściwości</strong></td><td></td><td></td></tr><tr><td><strong>Id</strong></td><td>id</td><td>Unikalny identyfikator techniczny pola (nadawany automatycznie przy dodawaniu komponenentu).</td></tr><tr><td><strong>Identyfikator biznesowy</strong></td><td>mid</td><td><p>Biznesowy identyfikator pola (domyślnie jest taki sam jak id, ale można go zmienić).<br><br>Identyfikator biznesowy (Mid) to jednoznaczny identyfikator powiązany z logiką biznesową. Po nadaniu go łatwiej nam będzie wyszukać konkretny komponent przy dodawaniu nasłuchiwań czy parametrów wejścia i wyjścia Page Services. Midu nie mają komponenty Etykieta (Text) i Treść formatowana (TextContent).</p><p>Identyfikator biznesowy powinnien być pisany camelCasem, nie powinien zawierać spacji i polskich znaków.<br><br><strong>UWAGA!</strong></p><p>Z racji tego, że model danych Uniflow opiera się na biznesowych identyfikatorach pól (mid) a nie na id, w przypadku wykorzystywania na wniosku modelu danych Uniflow nie mogą powtórzyć się biznesowe identyfikatory pól (np. mamy dwa różne komponenty o tym samym identyfikatorze biznesowym albo komponent ma ten sam mid co id zmienne sesyjnej).<br></p></td></tr><tr><td><strong>Etykieta</strong></td><td>label</td><td><p>Etykieta komponentu wyświetlana nad komponentem (atrybut nie jest obsługiwany w niektórych kanałach).</p><p><br></p></td></tr><tr><td><strong>Nieaktywne pole prezentowane jako etykieta</strong></td><td>labelIfDisabled</td><td><p>Zaznaczone (ustawione na "true") oznacza, że nieaktywny komponent wyświetlany jest jak tekst (na wniosku wygląda jak prezentowany jak etykieta).</p><p>Dostępność funkcjonalności zależy od licencji i może nie być dostępna we wszystkich wdrożeniach.</p><p>Wniosek demo: demoLabelIfDisabled</p></td></tr><tr><td><strong>Pomoc kontekstowa</strong></td><td>toolTips</td><td><p>Definiowanie dynamicznej pomocy kontekstowej dla komponentu w zależności od warunków.</p><p>Więcej w: <a href="/pages/v3B65hqT3xj4U3YapH4L">Pomoc kontekstowa - Tooltip</a></p></td></tr><tr><td><strong>Klucz modelu danych</strong></td><td>model</td><td><p>Dla pól mogących przyjmować wartości określa powiązanie dwustronne z modelem danych.</p><p>Więcej w: <a href="/pages/KG0pXEaHL87RO7XIlUyS">Przechowywanie danych w modelu</a></p></td></tr><tr><td>Sekcja <strong>Jakość danych</strong></td><td></td><td></td></tr><tr><td><strong>Warunek widoczności</strong></td><td>visibleCondition</td><td>Warunek widoczności pola (warunki wpisujemy z użyciem edytora opisanego w <a href="/pages/hXzjgFvoksjR8o8dGewt">Zaawansowany edytor warunków</a>).</td></tr><tr><td><strong>Warunek aktywności</strong></td><td>enabledCondition</td><td>Warunek możliwości edycji pola (warunki wpisujemy z użyciem edytora opisanego w <a href="/pages/hXzjgFvoksjR8o8dGewt">Zaawansowany edytor warunków</a>).</td></tr><tr><td><strong>Maksymalna długość wartości</strong></td><td>maxPropertyLength</td><td><p>Ze względów bezpieczeństwa każda wartość tekstowa w platformie (np.: zawartość pola tekstowego, wartość i opis listy rozwijanej, wartość radio itp.) jest weryfikowana pod względem długości. Domyślnie platforma nie przepuszcza ciągów znaków o długości przekraczającej 256. Jeżeli ze względu na wymagania biznesowe konieczna jest zmiana maksymalnej długości to można to zrobić za pomocą atrybutu <strong>Maksymalna długość wartości</strong>.<br>Dostępność funkcjonalności zależy od licencji i może nie być dostępna we wszystkich wdrożeniach.</p><p><strong>UWAGA!</strong></p><p>System posiada dodatkowy twardy limit (domyślnie: 10485760 znaków) - jest to nieprzekraczalny limit, który nie zostanie nadpisany przez wartość atrybutu Maksymalna długość wartości.<br></p></td></tr><tr><td><strong>Warunek wymagalności</strong></td><td>requiredCondition</td><td>Warunek wymagalności pola (warunki wpisujemy z użyciem edytora opisanego w <a href="/pages/hXzjgFvoksjR8o8dGewt">Zaawansowany edytor warunków</a>).</td></tr><tr><td><strong>Walidatory</strong></td><td>externalValidators</td><td><p>Definiowanie specjalizowanych walidatorów zewnętrznych.</p><p>Więcej w: <a href="/pages/lVPOHNqQ5rEO7wfdFB2Y">Walidacje złożone</a></p></td></tr><tr><td><strong>Wartość domyślna</strong></td><td>defaultValue</td><td>Dla pól mogących przyjmować wartości określa wartość początkową komponentu.</td></tr><tr><td><strong>Formater</strong></td><td>formatter</td><td>Patrz: <a href="/pages/QtuZa8iDFF99WgQsPvDk">Ustawienie formatowania dla komponentu</a>.</td></tr><tr><td><strong>Opis pola</strong></td><td>description</td><td>Tekst wyświetlany jako opis pola poniżej niego, domyślnie jest to wartość pusta.<br><br>Dostępność funkcjonalności zależy od licencji i może nie być dostępna we wszystkich wdrożeniach.</td></tr><tr><td>Sekcja <strong>Interakcje</strong></td><td></td><td></td></tr><tr><td><strong>Nasłuchiwanie</strong></td><td>listeningOn</td><td><p>Lista komponentów, od których zależny jest komponent. Zmiana wartości komponentów nasłuchiwanych spowoduje odświeżenie stanu komponentu.</p><p>Więcej w: <a href="/pages/zzKeW0m7KL1LeJuJGjIf">Nasłuchiwanie i czyszczenie</a>.</p></td></tr><tr><td><strong>Źródło danych zewnętrznych</strong></td><td>enternalDataSource</td><td><p>Definiowanie zewnętrznych źródeł danych.</p><p>Więcej w: <a href="/pages/j3qNIVPhV7mObqCBufU4">Zasilanie komponentów zewnętrznymi źródłami danych</a></p></td></tr><tr><td><strong>Wyczyszczenie pola</strong></td><td>clearOn</td><td>Lista komponentów, od których zależne jest wyczyszczenie danych wprowadzonych do komponentu.</td></tr><tr><td><strong>Źródło danych z innego pola</strong></td><td>valueSourceId</td><td>ID innego komponentu, który zapewni wartość dla danego komponentu (przykład użycia został opisany w: <a href="/pages/jgFYBEKKjFDwnFdNf2Ql">Przekazywanie wartości między komponentami lub stronami wniosku</a>).</td></tr><tr><td>Sekcja <strong>Bezpieczeństwo</strong></td><td></td><td></td></tr><tr><td><strong>Biała lista znaków</strong></td><td>extraWhitelistCharacters</td><td><p>Ze względów bezpieczeństwa każda wartość tekstowa w platformie (np.: zawartość pola tekstowego, wartość i opis listy rozwijanej, wartość radio, wartość grupy kafli itp.) jest weryfikowana pod względem dopuszczalnych znaków. Domyślnie platforma dopuszcza następujące klasy znaków:</p><ul><li>litery (łącznie ze znakami diakrytycznymi wszystkich języków),</li><li>cyfry,</li><li>znaki białe (różnego rodzaju spacje, tabulacje, znaczniki nowej linii itp.),</li><li>następujące znaki specjalne: '.' (kropka), ',' (przecinek), '-' (myślnik), '_' (podkreślnik).</li></ul><p>Jeżeli do serwera trafi wartość ze znakiem spoza listy to serwer przywróci ostatnią bezpieczną wartość. Jeżeli ze względu na wymagania biznesowe konieczne jest rozszerzenie listy znaków specjalnych na danym polu to można użyć do tego atrybutu <strong>Biała lista znaków</strong> (extraWhitelistCharacters). Wartością atrybutu jest ciąg znaków, które mają być dopuszczalne w danym polu.</p><p><strong>UWAGA!</strong></p><p>W przypadku rozszerzania listy dopuszczalnych znaków, ze względów bezpieczeństwa należy się upewnić, że usługi, do których będzie wysyłana ta wartość są gotowe na przyjęcie danego znaku oraz odpowiednio zabezpieczone.</p><p>Znak @ (małpa) domyślnie jest niedopuszczalny, o ile pole nie jest typu "email" (parametr <strong>Typ danych</strong> (expected type)).</p><p><strong>WAŻNE!</strong></p><p>W przypadku komponentów, które oprócz etykiety, mają również wartość (np. Radio grupa, Grupa kafli), i wartości te z jakiegoś powodu są różne (w kontekście niedozwolonych znaków), konieczne jest zdefiniowane w <strong>Biała lista znaków</strong> obydwu wartości - definiujemy to dla Grupy kafli, a nie dla pojedynczego Kafla.</p><p>Przykład: np. dla kafelka z etykietą "5+" zdefiniowano wartość option jako ">5" - w takiej sytuacji w białej liście jako dopuszczalne znaki musimy zdefiniować zarówno "+", jak i ">"</p><p>(stosowanie różnych wartości dla treści i wartości nie jest rekomendowanym rozwiązaniem, zaleca się stosowanie uspójnionych wartości).</p></td></tr><tr><td><strong>Pole techniczne</strong></td><td>technicalField</td><td>Pole wykorzystywane na wewnętrzne potrzeby logiki szablonu wniosku, nie jest propagowane do kolejnych systemów oraz nie jest widoczne na wniosku. Właściwość dostępna jest dla wybranych komponentów.</td></tr><tr><td>Sekcja <strong>Stylizacja</strong></td><td></td><td></td></tr><tr><td><strong>Nazwa stylów</strong></td><td>styleName</td><td>Nazwa stylu komponentu (w eximee Webforms odpowiada stylowi CSS, który zostanie nadany danemu komponentowi).</td></tr><tr><td>Sekcja <strong>Pozostałe</strong></td><td></td><td></td></tr><tr><td><strong>Automatyczna aktualizacja wartości</strong><br></td><td>autoServerUpdate</td><td><p>Automatyczne odsyłanie wartości do serwera (niezależnie czy na dany komponent coś nasłuchuje). Dodatkowo w przypadku zaznaczenia tej flagi przetwarzanie w grafie (po zmianie wartości) rozpoczyna się od komponentu, którego wartość się zmieniła (domyślnie przetwarzanie rozpoczyna się od jego następników).</p><p><strong>UWAGA!</strong></p><p>Ustawienie ma duży wpływ na wydajność platformy wnioskowej. Należy ją stosować wyłącznie w miejscach, w których jest wymagana (np. gdy używamy Suggestera). W sytuacjach wątpliwych prosimy o kontakt z zespołem Consdata.</p><p>Przykładowy wniosek z suggesterem i właściwością autoServerUpdate: test_autoserverUpdate.</p></td></tr><tr><td><strong>Tag GTM / Aktywowanie GTM</strong></td><td>gtmTagName/pushTagsToGtm</td><td>Możliwość skonfigurowania funkcjonalności <strong>Google Tag Manager</strong>. Domyślnie pole nie jest zaznaczone (wartość "false").</td></tr><tr><td><strong>Zbieranie statystyk</strong></td><td>getStats</td><td>Pole wykorzystywane do zbierania statystyk o danym komponencie. Domyślnie pole nie jest zaznaczone (wartość "false").</td></tr><tr><td><strong>Widoczność na wydruku</strong></td><td>printable</td><td>Określa czy komponent ma być widoczny na wydruku wniosku. Domyślnie pole jest zaznaczone (wartość "true").</td></tr><tr><td><strong>Zachowanie zmiany wartości, gdy komponent jest ukryty</strong></td><td>preserveValueWhenHidden</td><td><p>Flaga ta służy do zabezpieczenia zmiany wartości komponentu na domyślną, gdy zostanie on ukryty (lub jest on ukryty po odparkowaniu). Wartość komponentu zostanie zachowana również po zaparkowaniu i będzie możliwa do użycia w kolejnych sesjach. Domyślnie pole nie jest zaznaczone (wartość "false").</p><p>Funkcjonalność nie jest dostępna dla niektórych komponentów.</p></td></tr></tbody></table>

### Warunki widoczności <a href="#wspolnewlasciwoscikomponentow-warunkiwidocznosci" id="wspolnewlasciwoscikomponentow-warunkiwidocznosci"></a>

Dla każdego komponentu w panelu **Właściwości** można określić warunki jego widoczności, klikając **Dodaj warunek widoczności** w polu **WARUNEK WIDOCZNOŚCI** (dostępnym w sekcji **Jakość danych**). W wyświetlonym edytorze warunków można wprowadzać warunki zapisane prostym językiem wyrażeń (więcej w [Zaawansowany edytor warunków](/budowanie-aplikacji/logika-biznesowa/jezyk-wyrazen-definiowania-warunkow-warunki-z-getvalue/zaawansowany-edytor-warunkow.md)). Wykorzystywany język wyrażeń został opisany w [Język wyrażeń definiowania warunków](/budowanie-aplikacji/logika-biznesowa/jezyk-wyrazen-definiowania-warunkow-warunki-z-getvalue.md).

<figure><img src="/files/PX3owIr0U3YwtF8w1nJd" alt=""><figcaption><p><em><strong>Ilustracja 1.</strong> Pusta właściwość definiowania warunku widoczności</em></p></figcaption></figure>

Komponent jest widoczny jedynie w przypadku spełnienia warunku wpisanego w polu **WARUNEK WIDOCZNOŚCI**.

### Warunki wymagalności <a href="#wspolnewlasciwoscikomponentow-warunkiwymagalnosci" id="wspolnewlasciwoscikomponentow-warunkiwymagalnosci"></a>

Dla każdego komponentu w panelu **Właściwości** można określić warunki przy których komponent jest wymagalny, klikając **Dodaj warunek wymagalności** w polu **WARUNEK WYMAGALNOŚCI** (dostępnym w sekcji **Jakość danych**). Okno edycji warunku jest analogiczne do okna edycji warunku widoczności komponentów. Do definiowania warunków wykorzystywany jest język JavaScript opisany w [Język wyrażeń definiowania warunków](/budowanie-aplikacji/logika-biznesowa/jezyk-wyrazen-definiowania-warunkow-warunki-z-getvalue.md).

Komponenty, dla których warunek jest spełniony są wymagalne i nie jest możliwe przejście na kolejną stronę wniosku bez wprowadzenia wartości.

### Warunki komponentów w trybie tylko do odczytu <a href="#wspolnewlasciwoscikomponentow-warunkikomponentowwtrybietylkodoodczytu" id="wspolnewlasciwoscikomponentow-warunkikomponentowwtrybietylkodoodczytu"></a>

Dla każdego komponentu w panelu **Właściwości** można określić warunki, przy których komponent jest prezentowany w trybie tylko do odczytu, klikając **Dodaj warunek aktywności** w polu **WARUNEK AKTYWNOŚCI**. Okno edycji warunku jest analogiczne do okna edycji warunku widoczności komponentów. Do definiowania warunków wykorzystywany jest język JavaScript opisany w [Język wyrażeń definiowania warunków](/budowanie-aplikacji/logika-biznesowa/jezyk-wyrazen-definiowania-warunkow-warunki-z-getvalue.md).

Dla komponentów z niespełnionym warunkiem zablokowana jest możliwość edycji ich wartości podczas prezentacji wniosku.

### Nasłuchiwanie <a href="#wspolnewlasciwoscikomponentow-nasluchiwanie" id="wspolnewlasciwoscikomponentow-nasluchiwanie"></a>

Dla każdego komponentu można określić listę komponentów, na które nasłuchuje dany komponent (więcej w [Nasłuchiwanie i czyszczenie](/budowanie-aplikacji/interfejs-uzytkownika/formularze/dynamicznosc-formularza/nasluchiwanie-i-czyszczenie.md)).

Na podstawie nasłuchiwania tworzony jest graf zależności. W momencie zmiany stanu komponentu podgraf zależności zawierający wszystkie ścieżki kończące się na zmienianym komponencie jest sortowany topologicznie i komponenty w podgrafie są odświeżane. Odświeżanie komponentów następuje w kolejności wynikającej z sortowania topologicznego w taki sposób, że odświeżane są tylko te komponenty, których przynajmniej jeden bezpośredni poprzednik w grafie zmienił stan.

Cykle w grafie zależności rozwiązywane są arbitralnie (ucinane za komponentem leżącym głębiej w grafie)

Istnieje możliwość włączenia odświeżania wszystkich komponentów w grafie (niezależnie od tego czy bezpośredni poprzednik zmienił stan). Jest to czynność administracyjna i wymaga zmiany następującego wpisu w pliku /etc/eximee/webforms.xml:

```
<webforms>
    <server>
        ...
        <nonBlockingGraphFormTemplates>nazwa_szablonu1,nazwa_szablonu2</nonBlockingGraphFormTemplates>
    </server>
</webforms>
```

{% hint style="info" %}
Wniosek demo: demoWspolneWlasciwosciKomponentow
{% endhint %}


---

# 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/budowanie-aplikacji/interfejs-uzytkownika/formularze/praca-z-komponentami-bazowymi/wspolne-wlasciwosci-komponentow.md?ask=<question>
```

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.
