PHIALEGIS · PHIALEDRAWBOX

Historia kodu PhialeGis

Prace nad PhialeGis i jego komponentami trwają od grudnia 2023 roku.

Początek prac

Commity obejmujące strukturę projektu, motywy kontrolek i aplikację testową.

Geometria i DrawBox

Podstawy geometrii i komponent PhialeDrawBox z paskami przewijania.

Publiczna migawka repozytorium

PhialeTech.Platform udostępniono jako zapis wybranego etapu rozwoju.

Co tworzę

W PhialeTech pracuję nad komponentami .NET, które nie powinny być przywiązane do jednego frameworka graficznego. W repozytorium PhialeTech.Platform rozwijam też PhialeGis — aplikację GIS z modelem interakcji opartym na DSL. Główne kierunki obejmują Grid, DrawBox i edytor DSL, rozdzielenie logiki od renderowania oraz frontendy WPF i Avalonia. Adapter WinUI 3 jest na etapie szkieletu. Prace nad architekturą postępują; nie oznacza to, że wymienione komponenty zostały publicznie wydane.

Jedna logika, wiele interfejsów

Nie chcę utrzymywać osobnych implementacji tej samej logiki dla każdego frameworka UI. Dążę do tego, by decyzje komponentu — stan, obsługa danych, nawigacja, interakcje — były w Core, a frontend odpowiadał za tłumaczenie natywnych zdarzeń i renderowanie. Wspólne kontrakty mają izolować kod od typów konkretnego frameworka.

UniversalInput: wspólny język zdarzeń

Zdarzenia wejściowe w WPF, WinUI 3 i Avalonii różnią się od siebie zasadniczo, więc sama wspólna logika nie wystarcza. Dlatego rodzina Phiale opiera się na UniversalInput, bibliotece neutralnych zdarzeń wejściowych wspólnej dla tych platform. Adapter każdego frameworka tłumaczy zdarzenia natywne na zdarzenia UniversalInput, a Core pracuje już tylko na nich. Dzięki temu Core jest wspólny, a frontend dla danej platformy pozostaje cienką warstwą renderującą i adaptującą zdarzenia. Obecnie działają frontendy WPF i Avalonia; adapter WinUI 3 jest na etapie szkieletu.

Grid jest częścią większego ekosystemu

PhialeGrid nie jest jedynym elementem, który rozwijam. Obok niego są DrawBox, edytor DSL i PhialeGis. Właśnie dlatego zwracam uwagę na spójność modeli wejścia, API i sposobu zarządzania stanem. Nie chcę optymalizować jednego komponentu kosztem pozostałych.

Uprawnienia w interfejsie, weryfikacja na serwerze

Każdy komponent Phiale deklaruje manifest swoich możliwości, na przykład zmianę kolejności kolumn czy edycję podsumowań. Programista decyduje, czy dana instancja je udostępnia, a o tym, czy zobaczy je konkretny użytkownik, decydują jego uprawnienia (RBAC). Komponent deklaruje też, jakimi danymi się zajmuje, na przykład Klienci, więc możliwość edycji wynika z uprawnień read, write i delete do tych danych. Dane z serwera mogą dodatkowo nieść atrybuty (ABAC), które blokują na przykład edycję wybranego rekordu; warunek wylicza backend. Kontrola w interfejsie jest wygodą dla użytkownika, a backend zawsze weryfikuje uprawnienia ponownie. Prace nad tym mechanizmem trwają.

Historia kodu i rola publicznego repozytorium

Publiczne repozytorium PhialeTech.Platform jest migawką wybranego etapu rozwoju, a nie aktualnego stanu PhialeGis. Historia kodu sięga co najmniej 15 grudnia 2023 roku; już 17 grudnia 2023 roku powstawały podstawy geometrii i komponent PhialeDrawBox. Kod pozostaje zastrzeżony; ewentualne pakiety binarne i warunki ich używania będę publikować oddzielnie.

Zakres projektu

  • Core niezależny od frameworka UI
  • Neutralny model zdarzeń UniversalInput i adaptery frontendu
  • Uprawnienia po stronie interfejsu (w trakcie prac): manifest możliwości komponentu, uprawnienia do danych (read, write, delete) i reguły atrybutowe wyliczane przez backend
  • PhialeDrawBox i edytor DSL jako odrębne elementy ekosystemu
  • PhialeGis i domenowe przepływy pracy oparte na DSL