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

Podstawowe własności komponentów

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.

Właściwość Eximee Designer	Nazwa atrybutu w Źródle	Opis
Sekcja Podstawowe właściwości
Id	id	Unikalny identyfikator techniczny pola (nadawany automatycznie przy dodawaniu komponenentu).
Identyfikator biznesowy	mid	Biznesowy identyfikator pola (domyślnie jest taki sam jak id, ale można go zmienić). 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). UWAGA! 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).
Etykieta	label	Etykieta komponentu wyświetlana nad komponentem (atrybut nie jest obsługiwany w niektórych kanałach).
Nieaktywne pole prezentowane jako etykieta	labelIfDisabled	Zaznaczone (ustawione na "true") oznacza, że nieaktywny komponent wyświetlany jest jak tekst (na wniosku wygląda jak prezentowany jak etykieta). Dostępność funkcjonalności zależy od licencji i może nie być dostępna we wszystkich wdrożeniach. Wniosek demo: demoLabelIfDisabled
Pomoc kontekstowa	toolTips	Definiowanie dynamicznej pomocy kontekstowej dla komponentu w zależności od warunków. Więcej w: Pomoc kontekstowa - Tooltip
Klucz modelu danych	model	Dla pól mogących przyjmować wartości określa powiązanie dwustronne z modelem danych. Więcej w: Przechowywanie danych w modelu
Sekcja Jakość danych
Warunek widoczności	visibleCondition	Warunek widoczności pola (warunki wpisujemy z użyciem edytora opisanego w Zaawansowany edytor warunków).
Warunek aktywności	enabledCondition	Warunek możliwości edycji pola (warunki wpisujemy z użyciem edytora opisanego w Zaawansowany edytor warunków).
Maksymalna długość wartości	maxPropertyLength	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 Maksymalna długość wartości. Dostępność funkcjonalności zależy od licencji i może nie być dostępna we wszystkich wdrożeniach. UWAGA! 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.
Warunek wymagalności	requiredCondition	Warunek wymagalności pola (warunki wpisujemy z użyciem edytora opisanego w Zaawansowany edytor warunków).
Walidatory	externalValidators	Definiowanie specjalizowanych walidatorów zewnętrznych. Więcej w: Walidacje złożone
Wartość domyślna	defaultValue	Dla pól mogących przyjmować wartości określa wartość początkową komponentu.
Formater	formatter	Patrz: Ustawienie formatowania dla komponentu.
Sekcja Interakcje
Nasłuchiwanie	listeningOn	Lista komponentów, od których zależny jest komponent. Zmiana wartości komponentów nasłuchiwanych spowoduje odświeżenie stanu komponentu. Więcej w: Nasłuchiwanie i czyszczenie.
Źródło danych zewnętrznych	enternalDataSource	Definiowanie zewnętrznych źródeł danych. Więcej w: Zasilanie komponentów zewnętrznymi źródłami danych
Wyczyszczenie pola	clearOn	Lista komponentów, od których zależne jest wyczyszczenie danych wprowadzonych do komponentu.
Źródło danych z innego pola	valueSourceId	ID innego komponentu, który zapewni wartość dla danego komponentu (przykład użycia został opisany w: Przekazywanie wartości między komponentami lub stronami wniosku).
Sekcja Bezpieczeństwo
Biała lista znaków	extraWhitelistCharacters	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: litery (łącznie ze znakami diakrytycznymi wszystkich języków), cyfry, znaki białe (różnego rodzaju spacje, tabulacje, znaczniki nowej linii itp.), następujące znaki specjalne: '.' (kropka), ',' (przecinek), '-' (myślnik), '_' (podkreślnik). 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 Biała lista znaków (extraWhitelistCharacters). Wartością atrybutu jest ciąg znaków, które mają być dopuszczalne w danym polu. UWAGA! 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. Znak @ (małpa) domyślnie jest niedopuszczalny, o ile pole nie jest typu "email" (parametr Typ danych (expected type)). WAŻNE! 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 Biała lista znaków obydwu wartości - definiujemy to dla Grupy kafli, a nie dla pojedynczego Kafla. 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 ">" (stosowanie różnych wartości dla treści i wartości nie jest rekomendowanym rozwiązaniem, zaleca się stosowanie uspójnionych wartości).
Pole techniczne	technicalField	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.
Sekcja Stylizacja
Nazwa stylów	styleName	Nazwa stylu komponentu (w eximee Webforms odpowiada stylowi CSS, który zostanie nadany danemu komponentowi).
Sekcja Pozostałe
Automatyczna aktualizacja wartości	autoServerUpdate	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). UWAGA! 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. Przykładowy wniosek z suggesterem i właściwością autoServerUpdate: test_autoserverUpdate.
Tag GTM / Aktywowanie GTM	gtmTagName/pushTagsToGtm	Możliwość skonfigurowania funkcjonalności Google Tag Manager. Domyślnie pole nie jest zaznaczone (wartość "false").
Zbieranie statystyk	getStats	Pole wykorzystywane do zbierania statystyk o danym komponencie. Domyślnie pole nie jest zaznaczone (wartość "false").
Widoczność na wydruku	printable	Określa czy komponent ma być widoczny na wydruku wniosku. Domyślnie pole jest zaznaczone (wartość "true").
Zachowanie zmiany wartości, gdy komponent jest ukryty	preserveValueWhenHidden	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"). Funkcjonalność nie jest dostępna dla niektórych komponentów.

Warunki widoczności

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). Wykorzystywany język wyrażeń został opisany w Język wyrażeń definiowania warunków.

Ilustracja 1. Pusta właściwość definiowania warunku widoczności

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

Warunki wymagalności

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.

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

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.

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

Nasłuchiwanie

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).

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>

Wniosek demo: demoWspolneWlasciwosciKomponentow