Egzotyka z zasady jest lepsza od nudy. Kiedy nie możemy sobie pozwolić na egzotykę, a z pewnych ważnych względów w systemach informatycznych właśnie tak jest, pozostaje zrekompensować ten brak - różnorodnością elementów składowych. Przyjemność, jaką można by czerpać z obcowania z systemem informatycznym, gdyby jego interfejs składał się tylko z tabelek - można określić jako umiarkowaną. Z drugiej strony interfejs przepełniony nieszablonowymi, nieustandaryzowanymi elementami byłby trudny w obsłudze i wymagałby szkoleń z długą krzywą nauczania.

W NEXT radzimy sobie z tym w dość prosty, jak się wydaje, ale skuteczny sposób. Oprócz standardowych elementów prezentacji danych, które już poznaliśmy: tabela, szczegóły, drzewo - dostępne są widoki specjalizowane do użycia w pewnych specyficznych miejscach systemu. Z zastrzeżeniem, że pozostają one standardowymi komponentami platformy - co zapewnia łatwość ich użycia. Pierwszym specjalizowanym widokiem jest widok kalendarza. Przykładem jego zastosowania jest prezentacja aktywności operatora.

Jak widać - widok jest dosyć złożony, z lewej strony mamy kalendarz pozwalający wybrać zakres dat, z którego będą prezentowane dane oraz opcjonalnie dla kalendarza grupowego listę podmiotów (w tym przypadku operatorów) z możliwością wyboru. W górnym prawym rogu mamy możliwość ustalenia stopnia powiększenia oraz przełącznik układu widoku, dzienny, tygodniowy oraz miesięczny. W środkowej części mamy obszar roboczy gdzie wyświetlane są elementy danych, w tym konkretnym przypadku -aktywności operatora. Kalendarz może zostać użyty do dowolnego innego celu w innym miejscu systemu, ważne jest aby dane na nim prezentowane zawierały informację o czasie rozpoczęcia i zakończenia. Jak wiadomo każdy widok w platformie pobiera dane w oparciu o dostawcę danych, dla w/w widoku dostawca danych może wyglądać tak:

Definiując dostawcę danych do kalendarza musimy dostarczyć informacje o strukturze danych - i tak: czy kalendarz jest wielopodmiotowy, np. kalendarz grup operatorów jest wielopodmiotowy gdyż można na nim w jednym momencie oglądać zadania dla wielu osób (linia 44), jaka jest nazwa podmiotów kalendarza np. „Operatorzy” dla kalendarza grup operatorów (39), jaka jest definicja zapytania o elementy wyświetlane na kalendarzu np. aktywności operatora (27), jaka jest definicja zapytania o podmioty wielopodmiotowego kalendarza np. zapytanie o operatorów dla zadanej grupy (33) i wreszcie na końcu jaka jest definicja zapytania o dane które stanowią tło kalendarza, czyli czasy dostępności, czasy pracy i czasy przerw, zwolnienia, absencje (21). Każda z definicji zapytania jest już zwykłą, standardową definicją dostawcy danych, którą omawialiśmy przy widoku tabelarycznym. Pozostało już wstawić widok do interfejsu użytkownika, ale o tym w następnym wpisie.

Kolejnym rodzajem widoku danych w platformie NEXT jest widok drzewa. Widok tan składa się z kolumn, analogicznie do widoku tabelarycznego, z tym że pierwsza kolumna wyświetla hierarchię wierszy w postaci drzewa. Taki sposób prezentacji danych pozwala czerpać korzyści z widoku drzewa a zachować funkcjonalności jakie daje widok tabeli i kolumn.

Jak widzimy widok drzewiasty może czerpać dane z dwóch rodzajów struktur: drzewiastej i hierarchicznej. Struktura drzewiasta oznacza że dany obiekt może wskazywać na obiekt nadrzędny oraz posiadać obiekty podrzędne, przy czym wszystkie obiekty w drzewie są tego samego typu a samo drzewo obrazuje tylko ich podrzędność nadrzędność, co ważne struktura taka ma dowolną ilość zagłębień np.

Struktura hierarchiczna natomiast występuje pomiędzy obiektami różnych typów, kiedy relacje pomiędzy tymi typami można ująć jako „nadrzędny – podrzędny”, struktura taka ma określoną i skończoną ilość zagłębień, wiadomo także jakiego typu obiekty znajdują się na każdym jej poziomie np.

Widok drzewa w platformie NEXT pozwala na łączenie i kombinowanie obu struktur np.

Widok drzewa w platformie NEXT budowany jest (tak jak każdy widok danych) w oparciu o dostawcę danych.

Główna metoda wypełniająca definicję danych dla drzewa to w linii (31) „defineContent()”. W w/w przykładzie drzewo składa się z jednego poziomu (37), który rozbudowuje się w drzewo po kolumnie wskazującej rodzica (41), jako etykietę gałęzi drzewa wyświetlamy nazwę (44) oraz wczytaną do zasobów ikonę (46), dodatkowo wybrane są do wyświetlania trzy kolumny (47..49). Jak widać kolejny raz programista biznesowy nie pyta o dane, nie wyświetla ich, deklaruje tylko w sposób opisowy platformie szczegóły danego widoku, pomijając potencjalnie kłopotliwą implementację.

Wiemy już jak przeglądać dane w postaci prostej i funkcjonalnej tabeli. Spójrzmy teraz na inne sposoby prezentacji danych w systemie VERTO. Pierwszym z nich jest szczegółowy widok wiersza. Jak wiadomo widok tabelaryczny ma pewne ograniczenia, pierwszym z nich jest limitowana szerokością ekranu ilość kolumn która nie może być zbyt duża aby nie zmniejszać czytelności całego widoku. Drugie ograniczenie także związane jest z dużą ilością kolumn, i dotyczy wydajności. Pobieranie znacznej liczby kolumn z serwera w połączeniu z znaczną ilością wierszy (a to standard w widokach tabelarycznych) może znacząco obniżyć wydajność całego systemu. Konfrontując z tymi ograniczeniami potrzeby użytkowników, którzy chcą mieć szybki dostęp do znacznie większej ilości informacji niż zawiera tabela, dochodzimy do rozwiązania problemu, do wspomnianego wcześniej szczegółowego widoku wiersza. Widok ten może zostać połączony z widokiem tabelarycznym, otrzymuje w ten sposób „świadomość” na jakim wierszu aktualnie znajduje się tabela oraz jak zbudowane jest zapytanie do pobierania danych. Na podstawie tych informacji może zadać swoje własne zapytanie do bazy danych, pytając o znacznie większy zbiór kolumn z zastrzeżeniem pobierania danych z jednego aktualnego wiersza. Tym sposobem zaspokaja potrzeby użytkownika jednocześnie nie degradując wydajności systemu. Rodzi się pytanie „a co z sytuacją gdy użytkownik jest „nerwowy” i ciągle zmienia aktualny wiersz w tabeli, czy wtedy widok szczegółów „zalewa” serwer pytaniami o coraz to nowe dane?”. Tak by było gdyby nie fakt połączenia obu widoków gniazdem (o gniazdach będzie niebawem) z akumulacją zdarzeń, dla uproszczenia przyjmijmy że widok szczegółów wyśle zapytanie o dane dopiero kiedy użytkownik się „uspokoi” i zatrzyma się na jakimś wierszu. Zobaczmy zatem widok tabelaryczny w parze z widokiem szczegółów wiersza:

Oczywiście aby dodać widok szczegółów wiersza do widoku kontrahentów musimy ... przedstawić się platformie za pomocą wizytówki ... potem dostarczyć klasę implementacji ... nie, nie tym razem. Widok ten jest standardowym i gotowym do użycia komponentem platformy, do działania potrzebuje tylko połączenia z dowolnym widokiem tabelarycznym. Aktualnie widok ten jest opcjonalnie dodawany przez platformę do każdego widoku tabelarycznego więc nie trzeba wykonywać żadnych dodatkowych czynności. Analogicznie jak w tabeli, użytkownik może sam zdecydować jakie kolumny chce widzieć w danej chwili:

Warto zauważyć także że dane w widoku szczegółów wiersza są prezentowane przy zastosowaniu „formaterów” i „rendererów” zarejestrowanych w platformie oraz na fakt automatycznego podziału widoku na kolumny kiedy jego rozmiary na to pozwalają.

Prawdziwym początkiem procesu realizacji założonych celów jest wyrażanie intencji. W idealnie przyjaznym świecie sam taki akt deklaracji intencji powinien być wystarczający, w idealnie przyjaznym świecie cel powinien osiągnąć się sam. Zobaczmy jak ta "nierealna bajka" spełnia się w naszym „prawie idealnym” świecie, na platformie NEXT. Zobaczmy to na przykładzie działania komponentów typu "formatter" i "renderer".

W aplikacjach klienckich często zdarza się, że chcemy wpłynąć na sposób prezentacji danych na ekranie, chcemy określić format w jakim informacje mają być prezentowane i wyświetlane. Jako przykład rozważmy rzeczywiste przypadki z systemu VERTO: "Ustalanie formatu wyświetlania dla pól zawierających datę"

oraz "Wyświetlanie ikonki drukarki w polach które prezentują informację czy dany dokument powinien być wydrukowany"

W pierwszym przypadku musimy zdefiniować „formatter”. Zobaczmy jego wizytówkę i implementację:

Kod jest prosty i oczywisty :), wizytówka przedstawia nowy komponent platformie, a implementacja dostarcza ciągu znaków do wyświetlenia na podstawie daty. Istotny jest sposób w jaki mówimy platformie kiedy ma użyć formattera. W przykładzie mówimy w linii 26, aby ten formatter został użyty dla każdego pola, które jest typu „date”, bez względu na domenę oraz na widok, w którym ta kolumna występuje. Jest to najbardziej ogólna deklaracja zasięgu działania formattera. Platforma analizując zarejestrowane formattery czy renderery przegląda je od szczegółu do ogółu. Zaczyna od poszukiwania na najbardziej szczegółowym poziomie, dla widoku i kolumny w widoku czyli np. "saleDocument.documentCreateDate" potem dla samej nazwy kolumny "documentCreateDate" potem dla domeny "CreateDate", a na końcu dla typu danych "date", użyty zostanie pierwszy formatter, który zostanie znaleziony w tej właśnie kolejności. W kolejnym przykładzie z rendererem deklarujemy przypisanie do domeny "WaitForPrinting":

Dlaczego nie zarejestrowaliśmy reenderera do typu logicznego „boolean”? Ponieważ typ logiczny ma już swój ogólny renderer, a chcemy aby wyłącznie dla kolumn przypisanych do domeny "WaitForPrinting" następowało renderowanie obrazka drukarki dla wartości "true" i to niezależnie w jakim widoku pole takie wystąpi. Co warto zauważyć programista implementujący renderer nie musi sam rysować, daje wskazówki do rysowania, wiąże się to z tym że sam sposób rysowania może być różny w zależności od technologii klienckiej jakiej będziemy używać, więc staramy się stosować abstrakcyjne podejście i zwalniamy programistę z przykrego obowiązku rysowania.

Podsumowując: dostarczamy komponentów odpowiedniego typu, wyrażamy intencje w jakich sytuacjach mają zostać użyte, procesem wdrażania i realizacji zajmuje się platforma.

Platforma daje, ale platforma także wymaga. Co trzeba zrobić, aby uzyskać komponent widoku opisywany w poprzednich wpisach. Podstawowa zasada to "przedstawić się platformie" w formie wizytówki:

Dostarczyć pewnych informacji opisowych:

Widok jest gotowy, z tym że brakuje mu informacji jakie dane miałby wyświetlać, z jakich widoków i w jakim układzie. Widok będąc komponentem czysto prezentacyjnym nie zajmuje się w/w zadaniami, zadania te są delegowane do "zaprzyjaźnionego" z widokiem komponentu - o dosyć oczywistej nazwie - "dostawca danych". Dostawcę danych także, należy przedstawić platformie w formie wizytówki:

oraz zdefiniować jego zawartość w formie klasy samego dostawcy:

Przyjrzyjmy się dokładnie co zawiera ta klasa. W linii 23 i 24 deklarujemy chęć skorzystania z serwisu platformy udostępniającego dostawcę kontekstów połączeń z bazą danych. Jak widać dzieje się to w deklaratywny sposób - poprzez zadeklarowanie odpowiedniego prywatnego pola klasy (24) oraz dodania adnotacji PlatformService (23). W dalszej kolejności naszym zadaniem jest uzupełnienie treści metody createQueryDefinition(), której jedynym zadaniem jest zwrócenie obiektowej definicji zapytania w postaci instancji klasy QueryDefinition. W treści tej metody pobieramy od dostawcy kontekst połączenia (29), tworzymy pustą instancję definicji zapytania (32) do której dodajemy trzy widoki: Customer (35), CustomerHist (44) oraz Address (51). Do każdego widoku dodajemy możliwe do wybrania kolumny, oraz dwa podrzędne widoki łączymy z widokiem głównym za pomocą wskazania odpowiedniej relacji (48) (56). Na koniec zwracamy wypełnioną definicję zapytania (58).

Na potrzeby tego przykładu zawartość widoku została znacznie ograniczona, ale nie ma to wpływu na samą zasadę działania: komponent przedstawia się, wymaga i deklaruje, a platforma „ochoczo” przystępując do pracy wykonuje całą resztę. Gdyby ktoś powiedział że to i tak jest dużo pisania ... śpieszę donieść że znaczna część prezentowanego dzisiaj kodu została wygenerowana przy pomocy narzędzi platformy, ale to już temat na inną opowieść.

Kontynuując opis widoku tabelarycznego z poprzedniego wpisu, przybliżę parę technik które zostały w tym komponencie zaimplementowane - co ważne znacząco poprawiają komfort pracy oraz w jeszcze większym stopniu wpływają na zmniejszenie obciążenia warstwy przetwarzania i warstwy danych.

Stronicowanie to bardzo ważna funkcjonalność, która znacząco wpływa na wydajność systemu. Dane do widoku pobierane są paczkami co powoduje racjonalne obciążenie serwera oraz kanału sieciowego. Dla operatora nie ma tu żadnych negatywnych konsekwencji, pobieranie kolejnych stron odbywa się w tle i jest wręcz niewidoczne.

Adaptacyjny algorytm ustalania rozmiaru strony jest to algorytm dobierania ilości wierszy w paczce, istnieje pewne optimum, pewien złoty środek pomiędzy ilością paczek a ich rozmiarem. Jak znaleźć więc takie optimum. Najlepiej śledząc z jednej strony poczynania użytkownika, a z drugiej mierzyć czasy odpowiedzi z serwera. Jeżeli użytkownik wyświetlając widok nie przegląda kolejnych stron zatrzymując się na pierwszej, to wystarczy aby ta strona miała pewien mały startowy rozmiar, jeżeli przegląda widok w dół to warto zwiększyć rozmiar strony, aby nie obciążać serwera zbyt częstymi żądaniami, zwiększanie rozmiaru paczki należy zatrzymać w momencie kiedy jej rozmiar jest już na tyle duży że przy aktualnym obciążeniu serwera i szybkości łącza sam czas pobrania paczki jest znaczący.

Ładowanie z wyprzedzeniem to kolejny mechanizm widoku tabelarycznego poprawiający tym razem komfort używania. Użytkownik przeglądając widok w dół mógł by dojść do końca tabeli wierszy i następnie poczekać na wczytanie kolejnej paczki, spowodowało by to przerwy w płynności działania widoku. Aby temu zapobiec dane są czytane w osobnym wątku już w momencie kiedy użytkownik dochodzi do połowy paczki z wierszami, czyli z wyprzedzeniem. Daje to dużą szansę, że zanim użytkownik dojdzie do końca tabeli nowa paczka z wierszami będzie już na miejscu zapewniając płynność przeglądania.

Odświeżanie zawartości widoku z uwzględnieniem tylko tych zmian na serwerze które wpływają na zawartość widoku. Jeżeli w wyniku jakiejś akcji użytkownika dojdzie do poprawy, dodania czy usunięcia jakiegoś wiersza w bazie danych (platforma otrzymuje takie informacje z warstwy przetwarzania informując o tym zainteresowane widoki) a ten wiersz jest aktualnie wczytany do widoku, widok wykona selektywne odświeżenie tego jednego wiersza. Jeżeli liczba takich wierszy przekroczy pewien próg to aby nie odświeżać osobno wielu wierszy odświeżany jest cały widok.

Pewnie nasuwa Wam się pytanie: Skoro ten komponent jest taki fajny, to co trzeba zrobić aby go użyć? Ale to już w następnym wpisie :)

Interakcja człowieka z systemami informatycznymi wiąże się z wykonywaniem pewnych stałych czynności, jedną z takich czynności jest przeglądanie danych. Chciałbym dzisiaj przedstawić głównego aktora w tym właśnie procesie, a mianowicie widok tabelaryczny. To prosty klasyczny komponent, w zasadzie tylko „kolumny i wiersze”, ale jak przekonamy się dalej, na platformie NEXT zyskał wiele przydatnych funkcjonalności. Zacznijmy od przedstawienia możliwości. Przeglądanie danych w postaci tabelki, z możliwością zmiany szerokości kolumn oraz ich przemieszczania, z pełną świadomością aktywnego wiersza.

Sortowanie po wybranej kolumnie, lub kilku kolumnach, inicjowane za pomocą kliknięcia na kolumnie lub po wywołaniu akcji "Sortuj", z wbudowanym systemem kontroli wydajności procesu sortowania.

Wybór kolumn pozwalający dostosować widok do konkretnych potrzeb operatora, wyboru dokonuje się z wcześniej zdefiniowanego zbioru kolumn z połączonych ze sobą tematycznie widoków.

Mechanizm wyszukiwania pozwalający przeszukiwanie zawartości widoku zgodnie z wybranym algorytmem przeszukiwania. System jest skonstruowany tak, aby aby uniknąć skomplikowanego systemu podawania warunków na poszczególne pola na rzecz intuicyjnego wpisywania poszukiwanej wartości, a to właśnie widok ma sam zinterpretować te wartości i na podstawie konfiguracji szukania podjąć decyzję gdzie i jak szukać.

Mechanizm analiz dostarcza każdemu widokowi umiejętności podstawowego przeanalizowania, policzenia, zgrupowania i zsumowania wartości w kolumnach oraz zaprezentowania wyników w postaci tabelarycznej i w postaci wykresu. Analizy mogą być definiowane i zapisywanie do wielokrotnego i wygodnego użytku.

Mechanizm drukowania zawartości widoku dostarcza każdemu widokowi zdolności do wydrukowania swojej zawartości w mocno definiowanej postaci, z wyborem kolumn ich szerokości, definiowanym nagłówkiem, możliwością podliczania kolumn kwotowych. Definicje wydruków mogą być definiowane i zapisywanie do wielokrotnego i wygodnego użytku.

Przekroczyłem już wszystkie granice rozsądku w temacie długości wpisów na blog, więc o kolejnych mechanizmach (a jest ich jeszcze kilka) opowiem w następnym wpisie.

Nie mogę się powstrzymać i choć to nie jest głównym tematem tego bloga, pragnę donieść o dwóch bardzo ważnych wydarzeniach dla obu naszych zespołów NEXT i VERTO.
Właśnie ukończyliśmy pierwsze wdrożenie systemu VERTO u klienta. Nasz pierwszy klient to hurtowania działająca w branży motoryzacyjnej. Wdrożenie objęło moduły sprzedaży, zakupów, gospodarki magazynowej i rozrachunków. Czas trwania wdrożenia to dwa tygodnie. Całe przedsięwzięcie zakończyło się sukcesem, potwierdzonym zarówno przez przedstawiciela klienta jak i przez nasz zespół wdrożeniowy.
Drugim ważnym wydarzeniem było pierwsze szkolenie z platformy NEXT zatytułowane „Wprowadzenie do tworzenia rozszerzeń systemu VERTO na platformie NEXT”. Szkolenie zgromadziło liczną grupę uczestników, po trzech dniach wykładów, warsztatów i dyskusji uczestnikom udało się stworzyć wdrożyć i uruchomić w pełni działające rozwiązania rozbudowujące istniejącą funkcjonalność systemu VERTO w zakresie modułu sprzedaży, a prowadzącym zebrać bardzo pochlebne opinie, wysokie oceny i bardzo cenne doświadczenia.

Kiedyś, (niestety) dawno temu, kiedy kupiłem kolejny zestaw Lego, mój starszy syn nie patrząc na obrazki na pudełku (które to ja bacznie oglądałem) rozerwał je i powiedział „dobra, dobra, zobaczmy jakie w tym są klocki”. My do tej pory postępowaliśmy inaczej. My czyli ja i Wy - osoby, które poświęcają czas na czytanie tego bloga, mam nadzieję. że takie są (serdecznie pozdrawiam). Postępujemy inaczej gdyż prawie wszystkie poprzednie wpisy były jak oglądanie pudełka - przyglądaliśmy się platformie z wysokiej perspektywy, omawiając założenia, koncepcje, idee. Nadszedł czas zajrzeć do środka ... „dobra, dobra, jakie tam są klocki”. Pierwszy klocek wypadł już nam z pudełka w poprzednim wpisie (nie myślcie tylko że pudełko jest dziurawe :)). Tym pierwszym klockiem była akcja inicjująca proces dodania kontrahenta. Kontynuujmy więc przegląd w warstwie prezentacji. Po kolei: akcje (action), widoki (view), opcje (option), moduł (modul), okna opcji (optionFrame), dostawcy danych (databaseContentProvider), moduły danych (dataModule), słowniki (dictionary), filtry (filter), modyfikatory (modyficator), formatery (formatter), renderery (renderer) to te najważniejsze. Przyswoimy sobie ich funkcje w platformie.

Akcje już znamy, akcja inicjuje pewną czynność, wizualnie jest ikoną lub pozycją w menu.

Widok z założenia to pewien obszar na którym coś jest wyświetlone, poza ogólnym pojęciem są bardziej specjalizowane widoki np. widok tabelaryczny, widok drzewiasty.

Opcja to symbol i zgrupowanie innych komponentów wokół pewnego pojęcia merytorycznego, takim pojęciem mogą być „Dokumenty sprzedaży”, „Jednostki miary” .

Moduł to pojęcie jeszcze szersze, moduł logicznie i merytorycznie grupuje opcje. np. moduł „Sprzedaż”, „Rozrachunki”, „Administracja”.

Okno opcji to okno w którym można wykonać wszystkie czynności związane z daną opcją takie jak przeglądanie, wyszukiwanie, edycja, drukowanie, słowem jest to kontener na widoki, akcje, miejsce gdzie łączą się one w celu dostarczenia założonej funkcjonalności.

Moduł danych zajmuje się wszystkim co jest związane edycją danych, domyślnie obsługuje cztery podstawowe czynności z zakresu CRUD, dodanie nowego „Create”, odczytanie istniejącego „Read”, poprawa „Update” oraz usunięcie „Delete”.

Słownik to specjalna konstrukcja pozwalająca w łatwy sposób wybrać coś ze spisu/słownika np. wybór kontrahenta na dokumencie, wybór kartoteki na pozycji dokumentu, wybór jednostki miary na kartotece.

Filtr ma za zadanie zawężać zakres danych w widokach do których jest podłączony, np. widok dokumentów sprzedaży jest filtrowany wg miejsc sprzedaży, w należnościach i zobowiązaniach możemy filtrować przeterminowane dokumenty.

Modyfikator a w zasadzie różne jego odmiany pozwalają zmieniać kształt zdefiniowanych już wcześniej obiektów, np. można modyfikatorem okna opcji dodać ikonkę lub widok do okna kontrahentów.

Formatery i rednerery pozwalają na zdefiniowanie sposobu prezentacji wartości w kolumnach widoków.

To podstawowy zestaw komponentów w warstwie prezentacji, jak widać są to pojęcia wyższego rzędu, proste i łatwe do przyswojenia, nie trzeba być programistą aby zrozumieć ich rolę. W następnych wpisach omówimy dokładnie i zobaczymy w działaniu każdy z typów komponentów platformy. Zapraszam.

„Teraz będzie hardkorowo” jak mawia jeden z moich ulubionych prezenterów :). To znaczy że po serii (mam nadzieję) w miarę strawnych wywodów teoretycznych zajrzymy pod maskę platformy. Zobaczmy jak wygląda dodanie do platformy w warstwie klienta akcji, która inicjuje proces dodania nowego kontrahenta, dokumentu czy innego obiektu biznesowego. Emanacją takiej akcji może być ikonka na pasku ikon, element w menu kontekstowym, reakcja na klawisz skrótu w kontekście okna kontrahentów lub dowolne inne miejsce w którym umieścimy tą akcję. Rejestracja takiej akcji w platformie polega na zarejestrowaniu wizytówki. Wizytówka to w zasadzie jedyna metoda na przedstawienie się platformie, która w odpowiedzi na ten „kulturalny gest” dokonuje rejestracji akcji i w ten sposób akcja staje się widoczna i dostępna do użycia dla innych komponentów np. okna opcji czy menu. Wizytówka wygląda tak:

...prawda że proste?! Rozszerzamy klasę DataModuleActionExtension, która jest bazową klasą dla wszystkich akcji związanych z wykonywaniem operacji na modułach danych, określamy identyfikator akcji ID, musi go mieć każdy komponent w platformie, w konstruktorze podajemy ten właśnie identyfikator, następnie identyfikator opcji, do której przynależeć ma akcja CustomerOptionExtension.ID, w tym przypadku jest to opcja kontrahentów oraz funkcję jaką będzie ta akacja „kazała” wykonać modułowi danych InsertFunctionExtension.ID, w tym przypadku jest to funkcja dodawania. I to już wszystko. Zostały jeszcze drobne kosmetyczne szczegóły, trzeba naszą akcję wyposażyć w ikonkę i tekst. Ikonką zajmować się nie trzeba, skoro wiadomo do jakiej opcji, należy akcja i skoro wiadomo jaką czynność realizuje, platforma pobierze ikonkę z opcji nałoży na nią ikonkę od czynności dodawania (obecnie „plusik”) i efekt gotowy. Co do tekstu to umieszczamy w pliku .properties jedną linie:

CustomerInsertAction.text = Dodaj kontrahenta

Oczywiście w przyszłości będzie trzeba zlokalizować ten tekst na inne języki, ale użycie plików .properties daje nam właśnie taką możliwość. W ten sposób nasza akcja jest gotowa do wysłania polecenia, dodania nowego kontrahenta do modułu danych.