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

• 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ń 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:

// 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 powinien 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. 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

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) 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ść:

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

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

• 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. _{(Dostępność funkcjonalności zależy od licencji i moze nie być dostępna we wszystkich wdrożeniach)}

• 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. _{(Dostępność funkcjonalności zależy od licencji i moze nie być dostępna we wszystkich wdrożeniach)}

• 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. _{(Dostępność funkcjonalności zależy od licencji i moze nie być dostępna we wszystkich wdrożeniach)}

• 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ę. _{(Dostępność funkcjonalności zależy od licencji i moze nie być dostępna we wszystkich wdrożeniach)}

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. 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. _{(Dostępność funkcjonalności zależy od licencji i moze nie być dostępna we wszystkich wdrożeniach)}

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

  _{(Dostępność funkcjonalności zależy od licencji i moze nie być dostępna we wszystkich wdrożeniach)}

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