Tabele

W bazie danych pojawił się pierwszy rekord! Ale my go nie widzimy i trzeba to naprawić. Aby to zrobić, potrzebny jest m.in. Table komponent (tabela, która wyświetli potrzebne dane). Zaraz po dodaniu poprosi Cię o decyzję, jakie dane będą się w niej znajdować oraz o wybranie modelu i punktu końcowego.

Ustawienia tabeli

Utworzoną tabelę należy natychmiast wydać zgodnie z wymaganiami użytkownika. Na przykład ograniczyć liczbę rekordów na jednej stronie (tabela może być bardzo długa i wielostronicowa), a także usunąć pola, które nie są interesujące lub ustawić żądane pole do wyjścia z powiązanych tabel.

Jednocześnie pamiętamy, że samo dodanie jakiegokolwiek komponentu nie oznacza jeszcze jego pełnej gotowości do pracy. Trzeba jeszcze stworzyć odpowiednie procesy biznesowe. W przypadku tabel wiele jest tworzonych automatycznie, ale w ramach szkolenia będziemy tworzyć wszystko od podstaw, aby lepiej przyswoić materiał.

Wyzwalacze tabel

W tabelach najbardziej interesujące są trzy wyzwalacze -. onDataUpdate, onShow, oraz onFilter. Zacznijmy od onShow i zdefiniujmy, co ma się stać, gdy tabela zostanie wyświetlona na ekranie. Będzie to wymagało trzech bloków:

1) Table Update Properties. Ustaw pożądane właściwości tabeli. Na przykład tutaj możesz ograniczyć liczbę rekordów na jednej stronie (ustaw parametr the Records per page = 10), a także pokazać, że strona jest w trybie ładowania danych (Loading = true)

2) Server request GET /country/. Aby dane mogły się pojawić, muszą zostać gdzieś pobrane. A żeby to zrobić, należy wykonać zapytanie do bazy danych o odpowiedni punkt końcowy. Jednocześnie zwróć uwagę na liczbę parametrów wejściowych tego punktu końcowego. Zapewniają one większą elastyczność zapytania i uzyskanie tylko tych danych, które są naprawdę potrzebne.
W naszym przypadku ustawimy _limit = 10 ponieważ liczba wpisów na stronę wynosi 10 i nie ma sensu ładować więcej. Dodatkowo zrobimy prawidłową kolejność wyjściową, posortujemy wszystko według nazwy (_sort_by = name), a także ustawimy kolejność sortowania. Parametr _sort_order parametr może przyjąć wartość ASC (od słowa Ascending, dla sortowania bezpośredniego, od najmniejszej wartości do największej) lub DESC (Descending, kolejność odwrotna). Bezpośrednie sortowanie alfabetyczne jest dla nas w porządku, więc _sort_order = ASC.

Parametr _with parametr zasługuje na szczególną uwagę. Wykonując zapytanie bez niego, moglibyśmy uzyskać jedynie dane o krajach. Ale model kraju jest związany z miastami i chociaż te dane nie należą do żądanej tabeli, nadal chcemy je zobaczyć. Aby to zrobić, ustawiamy _with = citys i od razu otrzymujemy dane o tym, jakie miasta znajdują się w tym kraju.

3) Table Update Data. Dane otrzymujemy, ale trzeba je przenieść do tabeli, aby można je było wyświetlić na ekranie. W tym celu przekazujemy wszystkie informacje (data) otrzymane w poprzednim bloku, a także całkowitą liczbę rekordów (count - Total Records), aby zrozumieć, ile stron powinno być w tabeli.

Kolejny wyzwalacz to. onDataUpdate. Dane w tabeli mogą być aktualizowane w wyniku różnych procesów biznesowych. A kiedy tak się stanie, najlepiej raz określić, co powinno się stać i nie umieszczać tych samych bloków w każdym procesie biznesowym. W naszym przypadku poprawne będzie użycie Table Update Properties ponownie, ale tym razem w celu usunięcia trybu ładowania (Loading = false), który został ustawiony wcześniej, i pokazać, że tabela jest gotowa do pracy.

Ostatni potrzebny nam wyzwalacz to. onFilter. Określa on, co ma się dziać w momencie przejścia na inne strony tabeli. W tym celu posiada on m.in. _offset parametr, który zgodnie z numerem strony wskazuje, jakie przesunięcie jest wymagane podczas ładowania danych.

Na przykład, jeśli w naszym przypadku na każdej stronie jest 10 wpisów, to na trzeciej stronie będą potrzebne wpisy od 21 do 30. Dane te zostaną uzyskane z _offset i mogą zostać przekazane do bloku Server request GET /country/ bloku. W przeciwnym razie proces biznesowy będzie całkowicie zbieżny z procesem na TableOnShow wyzwalaczu. W takich sytuacjach rozsądnie byłoby mieć dwa różne wyzwalacze uruchamiające ten sam proces biznesowy.

Jednak w naszym przypadku istotna różnica leży w parametrze _offset parametrze. Jeśli pozostawimy wszystko tak jak na poniższym zrzucie ekranu, to proces uruchomi się zgodnie z onShow ale zatrzyma się na bloku Server request GET /country/ ponieważ nie może uzyskać wartości _offset wartości (jest ona przekazywana z innego wyzwalacza).

Taką sytuację najlepiej rozwiązać za pomocą zmiennych. Przyjrzyjmy się konkretnemu przykładowi. Potrzebujemy zmiennej typu Integer do zapisania _offset wartość. Dlatego używamy jednego Integer bloku do zadeklarowania tej zmiennej, ale dwóch różnych Set Variable bloków do zapisania jej wartości, każdy związany z innym wyzwalaczem.

Zgodnie z Table onShow wyzwalacza, nie potrzebujemy żadnego przesunięcia, dane w tabeli są wyświetlane od samego początku i _offset = 0, więc ustawiamy Value = 0 w Set Variable bloku.

Gdy Table onFilter wyzwalacza, otrzymujemy już wartość _offset wartość i chcemy jej użyć, więc przekażemy _offset wartość wyzwalacza jako Value do Set Variable bloku.

W kolejnych krokach procesy biznesowe wyzwalaczy nie różnią się od siebie, więc dwa procesy biznesowe są połączone w jeden, każdy z własną wartością zmiennej całkowitej dla _offset parametru.