# Kroki i strony formularza

**Kroki** i **strony** to podstawowe elementy struktury formularza w Eximee Designer, które pozwalają organizować wieloetapowe formularze. **Krok** grupuje jedną lub więcej stron i reprezentuje logiczny etap formularza (np. etap zbierania danych współwłaścicieli firmy, danych o dochodach kredytobiorcy lub podsumowanie wniosku), a **strona** to pojedynczy ekran/podstrona zawierający konkretne pola i komponenty. Projektant definiuje w ten sposób ścieżkę nawigacji użytkownika – określa kolejność kroków, znajdujące się w nich strony oraz warunki ich wyświetlania. W interfejsie użytkownika kroki mogą być sygnalizowane za pomocą belki postępu (tzw. belki kroków) – jej widoczność konfiguruje się w zakładce **Właściwości.**

## Zakładka „Kroki” – edycja struktury formularza

Strukturą kroków i stron zarządzamy w zakładce **Kroki** edytora wniosku. Po otwarciu formularza zakładka ta jest domyślnie wyświetlana w trybie podglądu (tylko do odczytu). Widać tam listę wszystkich kroków i należących do nich stron – dla każdego elementu pokazany jest **identyfikator biznesowy (mid)**, **tytuł** (jeśli nadano) oraz **warunek widoczności** (wyrażenie warunkowe określające, czy dany krok/strona ma się wyświetlić).\
\&#xNAN;*Uwaga:* warunki te nie są w tym widoku wykonywane, a jedynie prezentowane informacyjnie.

Aby edytować strukturę, należy przełączyć zakładkę **Kroki** w tryb edycji (ikona „ołówka” – **Edytuj proces**) – może być konieczne uprzednie zwolnienie ewentualnej blokady roboczej (szkicu) formularza. W trybie edycji można dodawać i usuwać kroki oraz strony, edytować ich podstawowe właściwości, a także zmieniać kolejność za pomocą mechanizmu *drag & drop.* Należy przy tym pamiętać o kilku zasadach:

* **Nie można usunąć wszystkich kroków!** – w formularzu musi pozostać przynajmniej jeden krok.
* **Dodanie nowego kroku** automatycznie tworzy nową stronę wewnątrz tego kroku (krok nie może być pusty).
* **Usunięcie kroku** powoduje usunięcie wszystkich stron, które on zawiera.
* **Przenoszenie stron między krokami** odbywa się poprzez przeciąganie myszą. Można np. przeciągnąć stronę z jednego kroku do innego.
* **Usuwanie poszczególnych stron** lub kroków jest dostępne z menu kontekstowego (ikona „kosza” przy elemencie). Dla strony dodatkowo dostępna jest opcja „Otwórz”, która przenosi do edycji zawartości tej strony w zakładce **Wniosek**.

> **Tip:** Belka postępu (kroków) wyświetlana użytkownikowi może być w razie potrzeby ukryta – służy do tego opcja *Widoczność belki kroków* w zakładce **Właściwosci**.

### Właściwości kroków

**Każdy krok posiada zestaw podstawowych właściwości definiujących jego rolę w formularzu.**\
W Eximee Designer są one widoczne zarówno w zakładce **Kroki**, jak i w zakładce [**Źródło**](https://docs.eximee.com/budowanie-aplikacji/interfejs-uzytkownika/formularze/tworzenie-formularza/podglad-definicji-formularza-xml).\
W zakładce **Kroki** właściwości te są dostępne jako pola tekstowe, które można uzupełnić zgodnie z podpowiedziami wyświetlanymi w tych polach.\
W zakładce **Źródło** te same właściwości występują pod swoimi technicznymi identyfikatorami:

* id – unikalny identyfikator kroku (wewnętrzna nazwa techniczna). Kroki domyślnie otrzymują ID w formie `Step1`, `Step2` itd. Jego edycja dostępna jest jedynie z poziomu zakładki [**Źródło**](https://docs.eximee.com/budowanie-aplikacji/interfejs-uzytkownika/formularze/tworzenie-formularza/podglad-definicji-formularza-xml).
* **titleKey** – klucz tłumaczeniowy tytułu kroku. Domyślnie przyjmuje wartość `StepX.title` (gdzie X to ID kroku). Ustawienie lub edycja odpowiedniego tytułu jest możliwa w zakładce **Kroki** gdzie można szybko dodać lub edytować tytuł dla głównego języka wniosku lub zakładce **Tłumaczenia** po wyszukaniu interesujacego nas kroku gdzie mozna dodawać lub edytować tytuł dla różnych języków zawartych w wniosku.
* **visibleCondition** – warunek widoczności kroku, zapisany w postaci wyrażenia logicznego. Jeśli warunek jest **niespełniony**, dany krok zostanie **automatycznie pominięty** podczas prezentacji wniosku użytkownikowi. W warunku można odwołać się do wartości pól lub zmiennych sesyjnych (szczegóły składni patrz rozdział [*Język wyrażeń*](https://docs.eximee.com/budowanie-aplikacji/interfejs-uzytkownika/formularze/dynamicznosc-formularza/jezyk-wyrazen) w dokumentacji). Warunek można również skonfigurować w zakłądce **Kroki –** w polu „Dodaj warunek” przy odpowiednim kroku.\
  Przykładowo, aby krok był widoczny tylko gdy użytkownik zaznaczył checkbox o ID `GesCheckbox1`, warunek może wyglądać następująco:

```javascript
// Warunek widoczności kroku (przykład)
getValue("GesCheckbox1") == "true"
```

Ten warunek zwróci "true" w przypadku gdy checkbox1 zostanie zaznaczony, co spowoduje pojawienie się kroku, w którym warunek został użyty.

Pamiętaj, że id kroku jest wartością unikalną i najlepiej go nie zmieniać po utworzeniu kroków (jest on powiązany np. z kluczami tłumaczeń i logiką). Natomiast *tytuł* i *warunek widoczności* można w każdej chwili modyfikować – zmiany te wpływają na zachowanie i wygląd formularza podczas wypełniania.

## Właściwości stron

Każda strona formularza posiada rozbudowany zestaw właściwości, podzielonych w edytorze na sekcje tematyczne: **Podstawowe właściwości**, **Układ, Jakość danych**, **Interakcje**, **Stylizacja**, **WCAG** oraz **Pozostałe**. Aby edytować właściwości konkretnej strony, należy otworzyć tę stronę w trybie edycji w zakładce **Wniosek** (np. klikając na liście w zakładce Kroki nazwę strony lub wybierając opcję „Otwórz”) i następnie kliknąć w puste tło strony – w prawym panelu pojawią się właściwości strony.\
**Uwaga:** niektóre podstawowe właściwości (identyfikator, tytuł, warunek widoczności) można również zmieniać z poziomu listy w zakładce **Kroki**, jednak większość ustawień jest dostępna wyłącznie w edycji strony.

Poniżej zestawienie kluczowych właściwości strony według sekcji:

#### Podstawowe właściwości strony

* **Id** – unikalny identyfikator strony. Id automatycznie przyjmuje kolejną wartość `PageX` (gdzie X odpowiada nr strony) przy tworzeniu nowej strony i nie można go zmienić w edytorze graficznym – jest to tylko możliwe w zakładce **Źródło**. **Id** musi być unikalny w ramach formularza i jest widoczny w adresie url podczas wypełniania wniosku.
* **Identyfikator biznesowy (mid)** – opcjonalny „przyjazny” identyfikator strony. Domyślnie **mid** jest taki sam jak **Id** strony ale można nadać my własną nazwę biznesową. Jest również edytowalny w zakładce **Kroki,** klikając pierwszą kolumnę w wierszu strony. **Mid p**owinien być unikalny.
* **Tytuł** – tytuł strony wyświetlany użytkownikowi (np. Podsumowanie). Można wpisać tekst statyczny, pozostawić pusty lub uzupełnić w zakładce **Tłumaczenia** jeśli strona ma mieć tytuł w różnych językach.
* **Tytuł (klucz)** – klucz tłumaczenia tytułu strony. Działa analogicznie do *titleKey* kroku – pozwala zdefiniować tytuł w różnych językach (wartość domyślna to np. `PageX.title` gdzie X to numer strony). W zakładce **Tłumaczenia** można dodać odpowiednie wpisy dla tego klucza.
* **Numer strony** – numer porządkowy, wskazujący, którą z kolei stroną wniosku jest dany ekran. Jest to pole tylko do odczytu (system sam numeruje strony w kolejności ich występowania w strukturze).
* **Etykieta przycisku "Dalej/Wyślij"** – pozwala zdefiniować niestandardowy tekst nawigacyjnego przycisku przechodzenia do następnej strony bądź wysłania wniosku, widocznego na danej stronie(np. „Zobacz podsumowanie” zamiast „Dalej”). Domyślnie przycisk ma etykietę „**Dalej**” lub „**Wyślij** **wniosek**” na ostatniej stronie.
* **Etykieta przycisku "Dalej/Wyślij" (klucz)** – klucz tłumaczenia etykiety przycisku. Jest automatycznie uzupełniany przez formularz wartością `PageX.nextButtonLabel` (gdzie X to numer strony). Jeśli formularz jest wielojęzyczny, należy dodać odpowiednie wartości w zakładce **Tłumaczenia.**\
  \&#xNAN;*Hierarchia wyświetlania etykiety przycisku:* jeżeli dla strony nie zdefiniowano własnej etykiety przycisku, w polu stosowana jest etykieta podana z zmiennych sesyjnych `nextButtonText` / `submitButtonText`, a w dalszej kolejności wykorzystywane są globalne klucze platformowe (`iew.navigation.next` / `iew.navigation.submit`).

#### Układ

* **Liczba kolumn** – pole przedstawia liczbę kolumn zdefiniowaną dla danego formularza. Pole jest nieedytowalne z poziomu zakładki **Wniosek.** Zmiana w zakładce **Źródło** została opisana w [Edycji stron](https://docs.eximee.com/budowanie-aplikacji/interfejs-uzytkownika/formularze/tworzenie-formularza/edycja-stron)

#### Jakość danych

* **Warunek widoczności** – formuła (wyrażenie), która określa, czy strona ma być pokazana użytkownikowi. Jeśli warunek zwróci wartość `false`, strona zostanie pominięta podczas wyświetlania wniosku (użytkownik jej nie zobaczy). Warunki piszemy jako wyrażenia JavaScript – możemy korzystać z funkcji takich jak `getValue("idKomponentu")` (pobranie wartości komponentu o podanym identyfikatorze) czy `isVisible("idKomponentu")` (sprawdzenie widoczności komponentu). Więcej przykładów zostało opisanych w [Język wyrażeń definiowania warunków (warunki z getValue)](https://docs.eximee.com/budowanie-aplikacji/logika-biznesowa/jezyk-wyrazen-definiowania-warunkow-warunki-z-getvalue)\
  Edytor warunków podpowiada dostępne składnie, identyfikatory pól i nazwy zmiennych. Przykładowy warunek dla strony, która ma się pojawić tylko jeśli pole wyboru ma określoną wartość:

```javascript
// Strona widoczna tylko gdy wybrano w polu "typ" wartość "A"
getValue("typWniosku") == "A"
```

* **Walidatory** – pole które pozwala na podpięcie dodatkowych reguł sprawdzających poprawność danych wprowadzonych na stronie. Dodawanie walidatorów odbywa się poprzez dołączenie odpowiedniego walidatora skryptowego – wiecej informacji można znaleźć w sekcji [Walidacje złożone (własne)](https://docs.eximee.com/budowanie-aplikacji/interfejs-uzytkownika/formularze/praca-z-komponentami-bazowymi/walidacja-wartosci-komponentow/walidacje-zlozone-wlasne)

#### Interakcje

* **Nasłuchiwanie** – mechanizm odpowiadający za **dynamiczne odświeżanie** stanu strony/komponentu/zmiennej w reakcji na zmiany w nasłuchiwanych elementach. Oznacza to, ze jeżeli np. warunek widoczności strony odwołuje się do wartości innego komponentu, należy dodać ten komponent do atrybutu **Nasłuchiwanie**. Dzięki temu zmiana wartości tamtego komponentu spowoduje ponowne przeliczenie/odświeżenie warunku i ewentualne pokazanie/ukrycie strony. W atrybucie **Nasłuchiwanie,** można wskazać wiele komponentów.\
  Edycja odbywa się przez okno listy – po kliknięciu przycisku **Lista,** pojawia się popup z listą dostępnych komponentów. Można je wyszukać podając zarówno **Id** jak i **mid**. W popupie widoczne są również komponenty już wybrane - nie da sie wybrać dwa razy tego samego.\
  \&#xNAN;*Przykład:* jeśli strona ma **Warunek widoczności** zależny od pola `umowaCheckbox`, należy dodać `umowaCheckbox` do **Nasłuchiwania** tej strony. Analogicznie postępujemy dla warunków kroków – ponieważ krok nie ma własnego atrybutu nasłuchiwania, komponenty warunkujące jego widoczność dodajemy do nasłuchiwania pierwszej strony kroku.

#### Stylizacja

* **Nazwa stylu** – lista styli CSS przypisana do strony. Umożliwia nadanie stronie (oraz wszystkim jej elementom) indywidualnego wyglądu poprzez stylowanie w arkuszu CSS. Wartość wpisana w to pole będzie dodana jako klasa HTML do kontenera strony. Można tutaj wpisać wiele klas rozdzielonych spacją. *(Więcej informacji znajduje się w dokumentacji w sekcji* [Style formularza i style komponentu](https://docs.eximee.com/budowanie-aplikacji/interfejs-uzytkownika/formularze)*.)*
* **Przycisk dalej przyklejony (customPositionedNavbarCondition)** – warunek dla specyficznego zachowania przycisku nawigacyjnego „Dalej”/„Wyślij”. Jest to funkcja używana głównie w natywnych aplikacjach mobilnych – pozwala np. sprawić, że przycisk będzie zawsze widoczny na dole ekranu (przypięty), jeśli spełniony jest dany warunek. Po ustawieniu warunku na *true*, dla danej strony przycisk nawigacyjny zmieni swój sposób wyświetlania.\ <sub>*(Dostępność funkcjonalności zależy od licencji i moze nie być dostępna we wszystkich wdrożeniach)*</sub>
* **Ukryj przycisk rezygnacji ("X")** – flaga określająca, czy na stronie ma być widoczny przycisk anulowania (oznaczony iksem, zwykle w nagłówku formularza). Domyślnie w kanale mobilnym, taki przycisk jest wyświetlany, pozwalając przerwać wniosek. Zaznaczenie tej opcji spowoduje ukrycie go na danej stronie.\ <sub>*(Dostępność funkcjonalności zależy od licencji i moze nie być dostępna we wszystkich wdrożeniach)*</sub>
* **Ukryj przycisk wstecz** – flaga kontrolująca widoczność przycisku nawigacji wstecz (ze strzałką) w aplikacji mobilnej. W niektórych szablonach mobilnych obok tytułu formularza wyświetlany jest strzałka „wstecz” do poprzedniego ekranu – włączenie tej flagi usunie ten element na danej stronie.\ <sub>*(Dostępność funkcjonalności zależy od licencji i moze nie być dostępna we wszystkich wdrożeniach)*</sub>
* **Ukryj tytuł wniosku** – flaga decydująca o pokazywaniu tytułu całego wniosku na górze ekranu. W typowych wdrożeniach webowych tytuł formularza jest wyświetlany np. w nagłówku. Jeśli formularz ma własny tytuł graficzny lub po prostu chcemy zaoszczędzić miejsce, możemy ukryć domyślny tytuł zaznaczając tę opcję.\ <sub>*(Dostępność funkcjonalności zależy od licencji i moze nie być dostępna we wszystkich wdrożeniach)*</sub>

#### WCAG

* **Strona zawiera formularz** – flaga określająca, czy strona ma być traktowana przez technologię asystującą jako samodzielny formularz. Ustawienie tej opcji nada kontenerowi strony atrybut `role="form"`, co bywa wymagane dla spełnienia standardów dostępności WCAG (zwłaszcza gdy w ramach jednej aplikacji występuje wiele niezależnych formularzy). Szczegóły dot. tej właściwości opisuje sekcja [*WCAG – strona jako formularz*](https://docs.eximee.com/budowanie-aplikacji/interfejs-uzytkownika/formularze/tworzenie-formularza/zakladka-audyt-naruszenia-wcag/wcag-strona-jako-formularz). Włączenie tej opcji zwykle nie jest konieczne dla zwykłych stron wniosku (które i tak znajdują się wewnątrz głównego formularza całej aplikacji), ale może być użyteczne w nietypowych scenariuszach.

#### Pozostałe

* **Kurtyna** – konfigurowalny komunikat wyświetlany u góry strony w formie zasłony. Pozwala on np. zablokować interakcję z pozostałą częścią formularza dopóki użytkownik nie wykona jakiejś akcji lub po prostu wyświetlić wyróżnione ogłoszenie. **Kurtyny** mogą służyć jako bannery informacyjne. Właściwość ta umożliwia wybór wcześniej zdefiniowanej **Treści (TextContent)** jako komunikatu lub wpisanie komunikatu tekstowego.\ <sub>*(Dostępność funkcjonalności zależy od licencji i moze nie być dostępna we wszystkich wdrożeniach)*</sub>
* **Dolny pasek (bottom bar)** – dodatkowy pasek na dole strony (tylko w aplikacjach mobilnych) służący do prezentowania np. rozwijanej sekcji z dodatkowymi informacjami lub akcjami. Dostępnych jest kilka właściwości konfigurujących ten pasek:

  * *Czy rozwijać tekst? (expandable)* – zaznaczenie, czy dolny pasek ma zawierać **rozwijalną treść** (czyli początkowo zwinięty komunikat z opcją „rozwiń”). Domyślnie opcja jest włączona (pasek jest rozwijalny). Jeśli ją odznaczymy, pasek będzie stały (niezwijalny).
  * *Alternatywny wygląd (mode)* – włącza alternatywny sposób prezentacji paska. W zależności od wdrożenia może to oznaczać inną kolorystykę lub styl paska.
  * *Tekst przycisku rozwijania (showToggleTextKey)* – klucz tłumaczeń dla tekstu linku/przycisku, który rozwija pasek. Domyślnie może to być np. „Czytaj więcej”. Wpisując tutaj np. `bottom.expand`, należy dodać odpowiedni wpis w tłumaczeniach (np. *bottom.expand = "Pokaż więcej informacji"*). Analogicznie działa *Tekst przycisku zwijania (hideToggleTextKey)* – klucz dla tekstu opcji zwinięcia paska (np. „Ukryj szczegóły”).
  * *Warunek widoczności paska (visibleCondition)* – warunek logiczny określający, czy w ogóle pokazać dolny pasek na danej stronie. Jeśli np. pasek ma być widoczny tylko dla nowych klientów, można tu wpisać odpowiedni warunek.
  * *Treść rozwinięta (topTextContentName)* – nazwa artefaktu **Treść (TextContent)**, którego zawartość będzie wyświetlana po rozwinięciu dolnego paska. Pozwala to projektantowi stworzyć bogaty HTML (np. listę, tabelkę, linki) w komponencie **Treść** i osadzić go w pasku.
  * *Treść zwinięta (bottomTextContentName)* – analogicznie, nazwa artefaktu Treść z zawartością, która jest widoczna **przed rozwinięciem** paska (czyli krótki komunikat na pasku). Po kliknięciu „rozwiń” komunikat ten może zostać zastąpiony lub rozszerzony treścią *topTextContent*.

  <sub>*(Dostępność funkcjonalności zależy od licencji i moze nie być dostępna we wszystkich wdrożeniach)*</sub>
* **Warunek wymagalności zalogowania (loginRequiredCondition)** – warunek określający konieczność zalogowania użytkownika przed wyświetleniem strony. Jeśli zostanie tu zdefiniowany warunek (np. `getValue("czyKlientZalogowany") != "true"`), to w przypadku jego spełnienia system wymusi uwierzytelnienie użytkownika (logowanie) zanim strona zostanie pokazana. Ta funkcjonalność jest używana w scenariuszach, gdy część wniosku dostępna jest tylko dla zalogowanych użytkowników.

*Dodatkowo istnieją pewne właściwości strony dostępne tylko poprzez edycję XML (zakładka Źródło). Należą do nich m.in. `fixedColumns`/`inheritLayout` – związane z dziedziczeniem układu kolumn ze starej wersji silnika – czy `migratedLayoutOn` (znacznik migracji układu). W większości przypadków nie ma potrzeby ich ręcznej modyfikacji.*

## Dobre praktyki projektowe

Projektując strukturę kroków i stron warto kierować się kilkoma dobrymi praktykami, które ułatwią utrzymanie wniosku i zapewnią poprawne działanie logiki:

* **Przemyślane nazewnictwo:** Nazwy artefaktów (formularzy, komponentów, zmiennych) powinny być spójne i zrozumiałe. Ustal, czy używasz języka polskiego czy angielskiego i trzymaj się konwencji. **Id** i **mid** dla stron najlepiej nadawać tak, by odzwierciedlały ich zawartość lub rolę. Unikaj pozostawiania domyślnych nazw typu *Page1* – lepiej zastąpić je np. *DaneAdresowe* czy *Podsumowanie*. Dzięki temu łatwiej odnajdziesz się w strukturze, a identyfikatory biznesowe pojawiające się np. w warunkach będą bardziej czytelne.
* **Unikalne identyfikatory:** Każdy krok, strona i komponent powinien mieć unikalny **mid** (identyfikator biznesowy). System co prawda wymusza unikalność wewnątrz jednego formularza, ale jeśli duplikujesz artefakty lub kopiujesz fragmenty formularzy, łatwo przeoczyć powielone identyfikatory. Duplikaty **mid** mogą prowadzić do niepoprawnego działania warunków czy nasłuchiwania. Przy powielaniu elementów zawsze sprawdzaj i zmieniaj **mid** na unikalny. Podobnie klucze tłumaczeń – nie używaj jednego klucza do dwóch różnych tekstów.
* **Czytelność i modularność warunków:** Tworząc złożone wyrażenia warunkowe, dbaj o ich czytelność. Wykorzystuj nawiasy i konwencje nazewnicze, by jasno oddać intencję (np. `getValue("dochódNetto") > 0 && getValue("etat") == "true"` zamiast nieczytelnego ciągu). Unikaj powtarzania tej samej logiki w wielu warunkach – jeśli kilka pól lub stron korzysta z tego samego wyrażenia, rozważ wyciągnięcie go do jednej zmiennej sesyjnej lub do pola technicznego. Przykładowo możesz dodać **pole techniczne** o **mid** `czyKlientVIP` z domyślnym wyrażeniem oceniającym dane klienta, i potem w warunkach różnych kroków odwoływać się tylko do `getValue("czyKlientVIP")`. Taka **centralizacja wyrażeń** uprości zmiany w przyszłości (modyfikujesz formułę w jednym miejscu) i zmniejszy ryzyko błędów.\
  W Eximee można oznaczyć **pole tekstowe** jako **pole techniczne,** zaznaczajac odpowiednią opcje w **Właściwościach** pole tekstowego - w sekcji **Bezpieczeństwo**. Pole takie jest niewidoczne dla użytkownika, ale dostępne dla logiki – przydatne dla przechowywania wartości pomocniczych.
* **Testowanie logiki widoczności:** Po skonfigurowaniu warunków i nasłuchiwania zawsze **przetestuj różne scenariusze** wypełniania wniosku. Upewnij się, że kroki i strony pojawiają się i znikają zgodnie z założeniami w odpowiedzi na dane użytkownika. Testuj kombinacje odpowiedzi – zwłaszcza krawędziowe przypadki – aby uniknąć sytuacji, gdzie np. pewna ścieżka nawigacji omyłkowo omija ważną stronę. Pamiętaj o przypadku, gdy warunek odwołuje się do pola z wartością domyślną: jeśli pole kontrolujące jest niewidoczne, ale ma ustawioną domyślną wartość spełniającą warunek, to zależna strona/komponent **i tak się wyświetli**.\
  \&#xNAN;*Przykład*: pole radio ma domyślnie zaznaczoną pierwszą opcję „TAK” i warunkowo pokazujemy inne pole właśnie gdy jest „TAK” – nawet gdy radio jest ukryte, domyślna wartość *"TAK"* wciąż powoduje ujawnienie zależnego pola. Takie sytuacje należy świadomie obsłużyć, np. ustawić brak domyślnej odpowiedzi dla radio.
* **Porządek i spójność:** Utrzymuj porządek w strukturze – nie twórz zbędnych, pustych kroków, nie umieszczaj pojedynczych pól na osobnych stronach jeśli nie jest to konieczne (lepiej pogrupować tematycznie pola w ramach jednej strony, aby użytkownik nie musiał klikać „Dalej” dla każdej drobnej informacji). Staraj się też, by każdy krok odpowiadał logicznie jednemu tematowi procesu – ułatwi to zarówno użytkownikowi zrozumienie progresu, jak i Tobie ewentualną rozbudowę wniosku.
* **Nazewnictwo tłumaczeń:** Jeśli formularz jest dwujęzyczny, zadbaj o jednolite nazewnictwo kluczy tłumaczeń dla kroków i stron. Zwyczajowo używa się wzorca `StepX.title` i `PageX.title` . W zakładce **Tłumaczenia** łatwo przejrzysz wszystkie klucze – unikaj duplikatów lub niepotrzebnie podobnych wpisów.
* **Reużywanie komponentów:** Jeżeli pewien zestaw pól pojawia się w wielu miejscach, rozważ stworzenie [**komponentu złożonego**](https://docs.eximee.com/budowanie-aplikacji/interfejs-uzytkownika/komponenty-rozszerzone/komponenty-zlozone) zamiast duplikowania tych pól ręcznie w każdym miejscu. Ułatwi to wprowadzanie zmian i zachowanie spójności.
* **Parkowanie wniosku:** Jeśli Twój proces biznesowy dopuszcza parkowanie (zapisywanie robocze) przed wysłaniem, upewnij się, że w formularzu jest to poprawnie obsłużone. Standardowo Eximee pozwala użytkownikowi zaparkować wniosek przy pomocy przycisku „Zapisz i wróć później” (jeśli wdrożenie go przewiduje). Nie dotyczy to jednak kroków po punkcie zapisu – tam parkowanie wniosku jest niemożliwe, więc nie musisz nic dodatkowego robić.

## Debugowanie kroków i stron – lista kontrolna

Pomimo starań, w skomplikowanych wnioskach mogą pojawić się problemy z logiką nawigacji lub widoczności. Oto lista kontrolna, która pomoże znaleźć najczęstsze błędy:

1. **Krok/strona nie pojawia się w ogóle:**
   * Sprawdź warunek widoczności kroku oraz wszystkich nadrzędnych elementów. Być może warunek jest zawsze fałszywy (np. literówka w nazwie pola w wyrażeniu powoduje, że zawsze zwraca **false**).
   * Upewnij się, że identyfikatory użyte w Warunku widoczności istnieją i są poprawne.
   * Sprawdź, czy dany krok nie został umieszczony jako element innego kroku. Eximee nie obsługuje zagnieżdżonych kroków — każdy krok musi znajdować się na najwyższym poziomie struktury.
2. **Warunek widoczności nie działa dynamicznie:**

   Jeśli warunek bazuje na polu zmienianym przez użytkownika, a strona/krok nie pojawia się lub nie znika podczas interakcji, prawie na pewno brakuje **Nasłuchiwania**. Sprawdź, czy komponent zależny ma dodany **Nasłuchiwanie** na to pole. W przypadku braku, dodaj brakujące powiązania i przetestuj ponownie.
3. **Element wyświetla się, chociaż nie powinien:**\
   Typowa przyczyna to warunek odwołujący się do pola z wartością domyślną, o czym wspomniano wyżej. Jeżeli zależność jest bardziej złożona, sprawdź też, czy nie pomyliłeś operatorów (np. użycie `==` zamiast `!=`) lub typów danych (porównujesz tekst z liczbą?).\
   W debugowaniu warunków pomocne może być tymczasowe dodanie na formularzu pola tekstowego i ustawienie jego tekstu jako wynik problematycznego wyrażenia – zobaczysz wtedy „na żywo”, co jest zwracane przez dane wyrażenie.
4. **Problemy z nawigacją między krokami:**\
   Jeśli przycisk „Dalej” nie reaguje lub użytkownik utknął, upewnij się, że w danym kroku jest co najmniej jedna **widoczna** strona. Może się zdarzyć, że wszystkie strony w kroku zostały ukryte warunkami – wtedy po ukończeniu poprzedniego kroku system może nie mieć dokąd przejść. Rozwiązanie: albo zapewnić, że choć jedna strona zawsze się pojawi, albo warunkowo pominąć cały krok (warunek na kroku zamiast na każdej stronie osobno).
5. **Nie można edytować formularza (ikona edycji wyszarzona):** Prawdopodobnie formularz został zablokowany przez mechanizm szkicu (draft) – np. inny użytkownik go edytował i nie zapisał.\
   Można wycofać blokadę zgodnie z opisem w sekcji *Draft – szkic/kopia robocza*. W Eximee Designer w widoku listy formularzy przy zablokowanym artefakcie pojawia się odpowiednia informacja i opcja przejęcia szkicu.
6. **Sprawdzenie powiązań procesów:** Gdy używasz EximeeRouter2, zweryfikuj w konfiguracji Punktu zapisu nazwę procesu i mapping business key. Błędna nazwa procesu może spowodować, że po wysłaniu nic się nie wydarzy (wniosek zapisze się, ale proces nie wystartuje). W logach systemowych szukaj komunikatów dotyczących uruchomienia procesu.
7. **Logi i tryb developerski:** W razie trudnych do zdiagnozowania problemów skorzystaj z logów przeglądarki (konsola JS) oraz logów serwera Eximee. Zweryfikuj w zakładce **Źródło** czy właściwości kroków i stron są tam zgodne z oczekiwaniami (to pozwoli wyłapać np. niechcący nadpisane identyfikatory albo brakujące wpisy).
8. **Korzystaj z FAQ:** W razie wątpliwości zajrzyj do dokumentu **FAQ Eximee Designer** – wiele typowych problemów zostało tam opisanych wraz z rozwiązaniami. Np. wyjaśniono tam dlaczego komponent zależny może się pokazać mimo ukrycia kontrolki (wartość domyślna), czy co zrobić, gdy zmiany w komponencie złożonym nie są widoczne we wniosku.

Zastosowanie powyższej listy kontrolnej powinno pomóc w szybkiej identyfikacji większości błędów związanych z mechanizmem kroków i stron. Jeśli problem jest nietypowy, warto przeanalizować go krok po kroku, upraszczając warunki (np. tymczasowo ustawić je na `true`/`false` w celu odseparowania wpływu innych czynników) i dodając elementy diagnostyczne (pola techniczne, pola tekstowe itp.).

## Powiązania z innymi sekcjami dokumentacji

Mechanizm „Kroki i strony” jest ściśle powiązany z innymi aspektami tworzenia wniosku w Eximee. Dla pełnego zrozumienia i poprawnej konfiguracji warto zapoznać się również z poniższymi tematami dokumentacji:

* **Procesy i EximeeRouter2** – jeżeli formularz jest częścią większego procesu biznesowego, zapoznaj się z dokumentem [**Procesy**](https://docs.eximee.com/budowanie-aplikacji/proces-biznesowy/proces-jako-logika-biznesowa). Opisano tam, jak definiować i uruchamiać procesy w Eximee BPMS oraz jak Eximee Designer komunikuje się z EximeeRouter2 przy wysyłaniu wniosku. Zrozumienie tej integracji pozwoli lepiej wykorzystać akcje zapisu w **Punkcie zapisu** (np. przekazywanie zmiennych procesu, obsługa wyjątków).
* **Tłumaczenia** – zakładka **Tłumaczenia** w edytorze umożliwia dodawanie tłumaczeń tekstów używanych w formularzu (w tym tytułów stron, etykiet przycisków itp.). Pamiętaj, że klucze takie jak *titleKey* czy *labelForNextOrSubmitButtonKey* wymagają dodania odpowiadających wpisów w tym miejscu, inaczej użytkownikowi nie wyświetli się interesujaca nas treść.
* **Stylizacja i UX** – mechanizm kroków wpływa na doświadczenie użytkownika, dlatego warto poznać możliwości **stylizacji** formularza. W dokumentacji dot. stylów znajdziesz informacje, jak globalnie dostosować wygląd belki kroków, przycisków nawigacyjnych, czy układu stron. Np. istnieją *style platformowe* oraz możliwość dodawania własnych arkuszy CSS do wniosku. Odpowiednie sekcje (np. *Stylizacja komponentów*) pokazują przykłady użycia właściwości stylów.
* **WCAG – dostępność** – jeśli projekt wymaga zgodności ze standardem WCAG, koniecznie przeczytaj dedykowaną dokumentację **WCAG**. Zawiera ona wytyczne odnośnie budowy dostępnych formularzy, opisy funkcji takich jak *ariaLabel/Description*, audyt dostępności w edytorze oraz wskazówki tworzenia komponentów przyjaznych dla czytników ekranowych. W kontekście kroków i stron, upewnij się np. czy każdy krok jest logicznie oznajmiany (jeśli belka kroków jest ukryta, rozważ dodanie ukrytych nagłówków na stronach informujących o etapie). Flaga *role=form* wspomniana wcześniej również odnosi się do zaleceń WCAG.

Na zakończenie, mechanizm „Kroki i strony” stanowi szkielet każdego wniosku w Eximee Designer – opanowanie jego zasad pozwoli Ci budować rozbudowane, a zarazem przejrzyste formularze. Korzystaj z dokumentacji i powyższych wskazówek podczas pracy, a Twoje wnioski będą poprawnie nawigować użytkownika od pierwszego kroku aż do strony podziękowania w sposób przyjazny i zgodny z założeniami biznesowymi.