5 błędów w Mendix, które popełniają początkujący twórcy (i jak ich uniknąć)

Kiedy zaczynałem pracę z Mendix, najbardziej podobało mi się to, że bardzo szybko widać efekt swojej pracy. To duża zmiana w porównaniu do tradycyjnego programowania i właśnie to poczucie natychmiastowego rezultatu było dla mnie wtedy niezwykle motywujące. Tworzysz pierwsze microflowy, wrzucasz kilka widżetów z Marketplace, a w efekcie otrzymujesz niemal gotową aplikację. Dopiero po czasie przychodzi rzeczywistość — importy się sypią, tłumaczenia znikają, a logika zaczyna przypominać spaghetti.

W tym wpisie zebrałem 5 błędów w Mendix, które sam popełniałem na początku, oraz kilka sposobów, jak ich unikać.

1. Używanie tylko natywnego języka aplikacji

Dołączyłem kiedyś do projektu, w którym cała aplikacja była utrzymywana w jednym języku — po polsku. Problem pojawił się, gdy trzeba było zintegrować moduł z Marketplace, który wprowadził angielskie teksty i komunikaty. W efekcie interfejs wyglądał jak przypadkowa mieszanka dwóch języków, a część etykiet nie pasowała do kontekstu.

Anegdota z życia

W tej samej aplikacji napotkałem inny problem – do widgetu Data Grid 2 została dodana opcja „Empty selection caption”, w której Mendix domyślnie wpisał angielską wartość. Ponieważ aplikacja nie miała zaimplementowanego języka polskiego, nie mogłem skorzystać z opcji „Batch translate”. W praktyce oznaczało to konieczność ręcznej edycji każdego filtra i zmiany tekstu z osobna. To doświadczenie przekonało mnie, że zawsze warto mieć włączoną konfigurację wielu języków już na wczesnym etapie projektu, nawet jeśli aplikacja ma docelowo działać tylko w jednym.

Jak tego unikać

1. Ustaw główny język aplikacji na angielski.
2. Dodaj język polski (lub inny) jako tłumaczenie.
3. Dzięki temu unikniesz błędów przy imporcie widżetów i modułów.

2. Instalowanie wszystkiego jak leci z Marketplace

To kuszące — Marketplace jest pełen modułów, które wydają się przydatne: mapy, PDF-y, wykresy, eksporty, maile… więc instalujemy wszystko. Problem w tym, że większość z nich dodaje zależności, spowalnia builda i częściej staje się źródłem wykrytych podatności — szczególnie gdy pozostają w projekcie nieużywane i od dawna nieaktualizowane.

Jak tego unikać

1. Instaluj tylko to, czego faktycznie potrzebujesz.
2. Usuń nieużywane moduły i widżety, jeśli nie są już potrzebne.
3. Sprawdzaj datę ostatniej aktualizacji modułu — wiele starszych nie działa poprawnie z nowszym Mendixem.

3. Bałagan w strukturze projektu

To klasyka. Wszystko w module „Main”, setki microflowów i stron, ale bez wyraźnej struktury. Problemem nie jest brak logiki, ale jej organizacja, przeszukiwanie i czytelność. Warto podzielić projekt na osobne foldery, np. Microflows, Nanoflows, Pages, Resources — wtedy wszystko jest uporządkowane i znacznie łatwiej znaleźć potrzebny element.

Jak tego unikać

1. Twórz osobne moduły dla każdej funkcjonalności (np. Customer, Invoice, Reporting).
2. Grupuj logikę w odpowiednich folderach (Microflows, Nanoflows, Pages, Resources).
3. Stosuj spójną konwencję nazw: ACT_, SUB_, DS_, JS_. To podejście jest dobrze opisane w sekcji Best Practices w oficjalnej dokumentacji Mendix.

4. Zbyt wysokie uprawnienia do encji

Wielu początkujących daje wszystkim rolom pełne prawa do danych, „bo inaczej czegoś nie widać lub rzuca błędem z brakiem uprawnień”. Przykładowo, może się zdarzyć, że użytkownik z jednego działu ma dostęp do danych z innego działu – widzi więcej, niż powinien, co stanowi realne ryzyko dla bezpieczeństwa informacji.

Jak tego unikać

1. Definiuj Access rules z XPathem na encjach zamiast ukrywania elementów na stronie.
2. Testuj widoczność danych dla każdej roli osobno.
3. Ograniczaj prawa do Read/Write tylko tam, gdzie to konieczne.
4. Unikaj ustawiania na encji domyślnych praw 'Read, Write’ dla nowych ról — może to skutkować nadaniem zbyt szerokiego dostępu do danych.

5. Brak porządku w nazwach i utrzymaniu microflowów

Nie ma nic gorszego niż MF1, Test, Nowy, Customer. Po kilku miesiącach nikt nie pamięta, który microflow robi co, a utrzymanie staje się wyzwaniem. Warto też unikać używania nazw w języku polskim — lepiej stosować angielskie nazwy encji i microflowów, np. Customer zamiast Klient.

Jak tego unikać

1. Stosuj prostą konwencję nazw (np. Prefix_NazwaEncji_Akcja).
2. Dodawaj krótkie komentarze do kluczowych microflowów.

Przykład dobrego nazewnictwa według zaleceń Mendix Best Practices

1. ACT_Customer_New – microflow odpowiedzialny za tworzenie nowego klienta (akcja uruchamiana przez użytkownika).
2. SUB_Customer_Validate – submicroflow walidujący dane klienta.
3. DS_Customer_Retrieve – microflow typu Data Source pobierający dane klienta.

Zachowaj porządek od początku i traktuj refaktoryzację jako naturalną część procesu tworzenia oprogramowania.

Jeśli dopiero zaczynasz przygodę z Mendixem, potraktuj te zasady jako checklistę, do której warto wracać przy każdym projekcie. Mam nadzieję, że ten wpis będzie początkiem krótkiej serii o dobrych praktykach i prostych sposobach na lepszy start w świecie low-code Mendix — bez zbędnego teoretyzowania, za to z przykładami z codziennej pracy.