Rozszerzalność zarządzania interfejsem

Omówiona do tej pory rozszerzalność interfejsu dotyczy tylko wewnętrznych kontrolek POS. W przypadku zaistnienia potrzeby dodania nowej kontrolki, którą będziemy chcieli zarządzać możemy skorzystać z mechanizmu rozszerzalności zarządzania interfejsem. Mechanizm ten pozwala na rejestrowanie nowych typów kontrolek i określanie jakie jej właściwości będą zarządzalne. Oprócz tego możliwe jest również dodawanie zarządzania do właściwości już istniejących kontrolek oraz ukrywania zarządzania wskazanych właściwości.

Ukrywanie właściwości do edycji

Ukrycie właściwości skutkuje usunięciem jej pozycji z zarządzania interfejsem. Użytkownik mający dostęp do zarządzania interfejsem nie będzie mógł zmienić jej wartości. Kontrolka, której właściwość zostanie ukryta będzie miała ustawioną wartość na domyślną zdefiniowana w stylach. Jednakże, jeżeli domyślna wartość została zdefiniowana w pliku ModernUI.xaml, zostanie ona zignorowana (różnice pomiędzy definiowaniem wartości domyślnych opisane zostały w artykule Zarządzanie widokiem i jego elementami

Ukrywać możemy określone właściwości na konkretnej kontrolce unikalnie zidentyfikowanej za pomocą Layout Id. Metoda ukrywająca właściwości to DisablePropertiesForLayoutElement znajdująca się w klasie PropertiesManager. Parametry tej metody:

• layoutId (string) – parametr będący identyfikatorem kontrolki, której właściwość chcemy ukryć.
• properties (params DependencyProperty[]) – jeden lub więcej właściwości, które mają zostać ukryte dla danej kontrolki.

Przykład ukrycia właściwości Ikona (ImageKey) z kafla Nowy dokument (layout id NewSalesDocument):

PropertiesManager.Instance.DisablePropertiesForLayoutElement("NewSalesDocument", TileButton.ImageKeyProperty);

Uwaga. W powyższym przypadku zniknie ikona na kaflu Nowy document ponieważ domyślna wartość dla właściwości ImageKey została zdefiniowana w pliku ModernUI.xaml.

Przykład ukrycia właściwości Wysokość (Height) z przycisku Zatwierdź (AcceptButton) konfiguracji globalnej:

PropertiesManager.Instance.DisablePropertiesForLayoutElement("AcceptButton", FrameworkElement.HeightProperty);

Dodawanie nowych właściwości do edycji

W przypadku, gdy istniejąca kontrolka albo zupełnie nowa ma zdefiniowane własne właściwości, które będziemy chcieli, żeby były modyfikowalne w zarządzaniu interfejsem, należy je zarejestrować. Można to zrobić na dwa sposoby, w zależności od tego czy właściwość ma być widoczna tylko dla kontrolki w konkretnym miejscu lub też globalnie dla wszystkich wystąpień tej kontrolki.

W pierwszym przypadku (rejestracja widoczna tylko dla kontrolki we wskazanym miejscu) należy skorzystać z metody AddPropertiesForLayoutElement z klasy PropertiesManager. Parametry metody:

• layoutId (string) – unikalny identyfikator kontrolki (Layout Id),
• properties (params DependencyProperty[]) – właściwości kontrolki, które mają być zarządzalne

W drugim przypadku (rejestracja widoczna globalnie we wszystkich miejscach użycia kontrolki) należy skorzystać z metody RegisterControlProperties z klasy PropertiesManager. Parametry metody:

• controlType (Type) – typ kontrolki,
• properties (params DependencyProperty[]) – właściwości, które mają być widoczne dla kontrolki wskazanego typu
• baseTypeProperties (Type) – typ kontrolki bazowej, z której zostaną pobrane zarejestrowane już wcześniej właściwości i użyte do rejestracji właściwości tej kontrolki

Obsługa atrybutów

Aplikacji POS obsługuje atrybuty jednowartościowe synchronizowane z systemu ERP. Typy wspieranych atrybutów to: tekst, liczba, słownik, wartość logiczna, lista, data. Aby dana klasa atrybutu została przesynchronizowana do stanowiska POS, w systemie ERP (Altum) należy oznaczyć tę klasę do podglądu i/lub edycji w sekcji Comarch POS (dostać się tam można poprzez zaznaczenie zakładki „Konfiguracja”, następnie „Atrybuty” i na końcu poprzez wybranie odpowiedniego atrybutu). Atrybuty mogę być prezentowane w postaci kolumn na liście (kontrolka datagrid) lub też w postaci kontrolek (generowanych w zależności od typu klasy atrybutu, np. dla klasy typu tekst będzie to TextBox, podczas gdy dla typu słownik będzie to ComboBox).

Dodanie nowej klasy atrybutu do istniejącego widoku w POS

Każdy widok w aplikacji POS, który wspiera atrybuty jest powiązany bezpośrednio z pewnym obiektem systemu ERP. Przykładowo, widok Lista kontrahentów prezentuje atrybuty na liście w postaci kolumn. Może pokazać atrybuty wraz z ich wartościami przypisanymi tylko do obiektu Kontrahent w systemie ERP. W przypadku widoku paragonu, lista (datagrid) prezentuje klasy atrybutów powiązane tylko z obiektem Element paragonu (PAR), natomiast atrybuty prezentowane w prawym dolnym rogu ekranu w postaci kontrolek powiązane są z obiektem Paragon (PAR).

Lista widoków wspierających atrybutu wraz z powiązanymi obiektami systemu ERP

Aby wskazaną klasę atrybutu dodać do POS, należy ją oznaczyć jako Retail POS (pogląd lub/i edycja). Opcja pogląd umożliwi działanie atrybutu w trybie tylko do odczytu w aplikacji POS. Natomiast wybranie opcji edycja będzie skutkowało możliwością zmiany wartości atrybutu, a po zapisie zmian przeniesienie tej informacji do systemu ERP. Następnie klasę atrybutu wiążemy z odpowiednim typem obiektu, który po stronie POS jest obsługiwany (parz tabelka powyżej). Po dodaniu i przesynchronizowaniu ustawień nowe atrybuty pojawią się na odpowiednim widoku w aplikacji POS i będą mogły być zarządzalne z poziomu konfiguracji interfejsu przez użytkownika POS.

Przykładowo dodajemy nową klasę atrybutu o nazwie X typu tekst, oznaczamy do edycji w sekcji Retail POS. Następnie wiążemy ją z obiektem Kontrahenta w systemie ERP. Po przesynchronizowaniu danych uruchamiamy aplikację POS i wchodzimy do konfiguracji widoku Dodaj kontrahenta. Tam zaznaczmy odpowiedni kontener (CustomerItemsContainer) pozwalający na prezentację atrybutów, a następnie z listy dostępnej po prawej stronie przeciągamy nasz nowy atrybut X na widok i upuszczamy go w odpowiednim miejscu.

Dodanie nowej klasy atrybutu do nowego widoku nieposiadających jej obsługi

Wsparcie dla atrybutów możemy również dodawać we własnych widokach tworzonych w ramach rozszerzenia. Atrybuty mogę być prezentowane w postaci dynamicznie generowanych kolumn na liście (kontrolka DataGrid) lub też w postaci niezależnych kontrolek (rodzaj kontrolki będzie zależny od typu klasy atrybutu).

Atrybuty w postaci kolumn na liście DataGrid

W celu implementacji atrybutów na listach w postaci dynamicznie generowanych kolumn, należy w pierwszej kolejności dla encji danych zaimplementować interfejs IAttributable. Dostarcza on trzy właściwości, niezbędne do poprawnej obsługi atrybutów na listach. Dwie pierwsze właściwości Id oraz ObjectType należy ustawić zgodnie z encją. Id to identyfikator encji, natomiast ObjectType to typ encji. Trzecia właściwość Attributes to słownik, który będzie trzeba wypełnić podczas asynchronicznego pobierania danych dla listy. Do wypełniania tego słownika należy skorzystać z metody FillAttributesForList znajdującej się w serwisie IAttributesService. Zanim dane ze słownika będą mogły zostać wyświetlone najpierw lista musi wygenerować dodatkowe kolumny. Aby mogła to zrobić, podczas pierwszego pobrania danych (IsInitialization=true) należy ustawić właściwość AttributeClasses znajdującą się w klasie AsyncDataGridCollection. Do ustawiana tej właściwości należy skorzystać z metody GetAttributesClasses z serwisu IAttributesService. Metoda przyjmuje dwa parametry, pierwszy pozwala na ustalenie jakie klasy atrybutów powinny być prezentowane na danej liście, drugi natomiast filtruje, które z klas dla danych grup mają być widoczne. W przypadku, gdy drugi parametr będzie null, pobierane będą wszystkie klasy, z wybranych w pierwszym parametrze grup. Implementacja powinna być zrealizowana tak, aby filtrowanie klas atrybutów było zarządzalne w trybie design mode widoku. Dlatego w DesignViewModelu danego widoku należy wywołać metodę z drugim parametrem ustawionym na null. Pozwoli to na pobranie wszystkich klas i wygenerowanie wszystkich możliwych kolumn (domyślnie ukrytych). Natomiast w ViewModelu widoku  należy do drugiego parametru przekazać właściwość VisibileAttributesClassesList, który będzie zawierała listę klas atrybutów ustawioną w trybie design przez użytkownika. Metoda FillAttributesForList wypełnienia słownik Attributes. Wymaga przekazania dwóch parametrów. Pierwszy to lista encji (encja musi implementować IAttributable), drugi to lista identyfikatorów klas atrybutów, dla który należy uzupełnić każdą z encji wartościami tych klas atrybutów. W celu optymalizacji, nie pobierania zbyt wielu informacji drugi parametr ustawiamy przekazując właściwość VisibleAttributesClassesList.

Sortowanie dla kolumn, które zostały wygenerowane dla atrybutów, jest wyłączone.

Domyślnie wygenerowane kolumny dla atrybutów są ukryte. Aby je wyświetlić należy dla trybu design mode zaimplementować pobieranie wszystkich możliwych atrybutów dla danej listy, tak aby użytkownik miał możliwość wyboru kolumny i zdefiniowania widoczność a także innych właściwości.

Atrybutu prezentowane są w postaci tekstu w przypadku, gdy lista jest w trybie tylko do odczytu. Natomiast dla trybu edycji, generowane są w postaci odpowiednich kontrolek w zależności o typu danych. Dla typu logicznego będzie to CheckBox, dla listy oraz słownika ComboBox, a dla pozostałych typów TextBox.

Kompletny przykład implementacji Widok dokumentu handlowego z obsługują atrybutów

Atrybuty jako niezależne kontrolki

Alternatywnym sposobem prezentacji atrybutów w tworzonych widokach jest implementacja ich w postaci dynamicznie generowanych kontrolek zależnych typu klasy atrybutu. Kontrolki pozwolą nam również na wprowadzanie zmian w wartościach atrybutów. Implementację możemy podzielić na trzy etapy. Pierwszy to implementacja pobierania atrybutów i prezentowania ich w postaci kontrolek widocznych w zdefiniowanym kontenerze. Drugi etap to implementacja walidacji wartości w atrybutach. Natomiast trzeci etap to zapis wprowadzonych zmian w wartościach atrybutów. Przykład implementacji Widok dokumentu handlowego z obsługują atrybutów