# 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**](/budowanie-aplikacji/interfejs-uzytkownika/formularze/tworzenie-formularza/podglad-definicji-formularza-xml.md).\
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**](/budowanie-aplikacji/interfejs-uzytkownika/formularze/tworzenie-formularza/podglad-definicji-formularza-xml.md).
* **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ń*](/budowanie-aplikacji/interfejs-uzytkownika/formularze/dynamicznosc-formularza/jezyk-wyrazen.md) 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](/budowanie-aplikacji/interfejs-uzytkownika/formularze/tworzenie-formularza/edycja-stron.md)

#### 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)](/budowanie-aplikacji/logika-biznesowa/jezyk-wyrazen-definiowania-warunkow-warunki-z-getvalue.md)\
  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)](/budowanie-aplikacji/interfejs-uzytkownika/formularze/praca-z-komponentami-bazowymi/walidacja-wartosci-komponentow/walidacje-zlozone-wlasne.md)

#### 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](/budowanie-aplikacji/interfejs-uzytkownika/formularze.md)*.)*
* **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*](/budowanie-aplikacji/interfejs-uzytkownika/formularze/tworzenie-formularza/zakladka-audyt-naruszenia-wcag/wcag-strona-jako-formularz.md). 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**](/budowanie-aplikacji/interfejs-uzytkownika/komponenty-rozszerzone/komponenty-zlozone.md) 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**](/budowanie-aplikacji/proces-biznesowy/proces-jako-logika-biznesowa.md). 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.


---

# 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/tworzenie-formularza/kroki-i-strony-formularza.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.