Dane: typedef, kontrakt i mapowania

Budujemy typedef — kontrakt danych formularza — i łączymy go z polami.

Co powinno trafić do typedefu

• Pierwsza myśl: przepisać wszystkie kolumny tabeli. To nie zawsze dobre podejście. Typedef jest wysyłany na formularz, więc powinien zawierać tylko to, czego formularz potrzebuje.
• Przykład: CreatedAt i CreatedBy z tabeli nieobecności uzupełnia proces przy zapisie. Formularz ich nie pokazuje i nie zmienia, więc nie ma ich w kontrakcie.

Budowa typedefu

• Elementy przeciągasz na kanwę, tak jak komponenty formularza.
• Obiekt Absence, a w nim:
  • AbsenceId — Guid,
  • PersonId — Guid, dopuszcza null (nowy wniosek nie ma jeszcze wybranego pracownika),
  • DateFrom, DateTo — daty,
  • Duration — liczba dni,
  • Status — liczba,
  • Details — uwagi.
• Poza obiektem: pole techniczne Mode (dopuszcza null) — tryb formularza, czyli dodawanie albo edycja. Przyda się później w logice.
• Każdy element może być pojedynczy albo tablicą. Na razie zostawiasz wartości domyślne.
• Pól nie trzeba zawsze definiować ręcznie: typ obiektu może być referencją do istniejącej tabeli lub zapytania. Proste kontrakty budujemy jednak ręcznie, tak jak tutaj.

Mapowania

• Po zmianie typedefu na formularzu podświetla się przycisk aktualizacji kontraktu. Klikasz go, a pola kontraktu stają się dostępne na formularzu.
• Mapowanie to wskazanie, które pole formularza odpowiada któremu polu kontraktu: pracownik → PersonId, daty → DateFrom/DateTo, liczba dni → Duration, status → Status, uwagi → Details.
• Pole ukryte: Mode ma być na formularzu, ale niewidoczne. Wstawiasz kontener condition (wyświetlanie warunkowe), w nim pole tekstowe mode, a warunek wyświetlania ustawiasz na false. Pole znika z podglądu, ale dalej jest na formularzu i można je zmapować na Mode.

Zapamiętaj

Wygląd i dane to dwa osobne drzewa połączone mapowaniami. Formularz wie już, jakie ma dane i gdzie je pokazać. Brakuje tego, kto te dane dostarczy i zapisze — czyli procesu (następna lekcja).