PHIALEGIS · PHIALEDRAWBOX

PhialeGis code history

Work on PhialeGis and its components goes back to December 2023.

Early work

Repository commits covering project setup, visual-control themes and a test application.

Geometry and DrawBox

Geometry basics and the PhialeDrawBox component with scrollbars.

Public repository snapshot

PhialeTech.Platform was made available as a record of a selected development stage.

What I am building

In PhialeTech I work on .NET components that should not be tied to one UI framework. The PhialeTech.Platform repository also contains PhialeGis, a GIS application with a DSL-oriented interaction model. The main directions include Grid, DrawBox, and a DSL editor, separation of logic and rendering, and WPF and Avalonia frontends. A WinUI 3 adapter exists only as a skeleton. Architectural work continues; this does not mean the components are publicly released.

One logic layer, multiple frontends

I do not want to maintain separate copies of the same behavior for each UI framework. I aim to keep component decisions—state, data handling, navigation, and interactions—in Core, with frontends translating native events and rendering the results. Shared contracts isolate this logic from framework-specific types.

UniversalInput: a common language for input events

Input events in WPF, WinUI 3 and Avalonia differ fundamentally, so shared logic alone is not enough. That is why the Phiale family is built on UniversalInput, a library of framework-neutral input events shared across these platforms. Each framework’s adapter translates native events into UniversalInput events, and Core works only with those. As a result Core is shared, and the frontend for a given platform stays a thin layer for rendering and event adaptation. WPF and Avalonia frontends work today; the WinUI 3 adapter exists only as a skeleton.

The Grid is part of a wider ecosystem

PhialeGrid is not the only component I develop. DrawBox, the DSL editor, and PhialeGis are part of the same work. That is why I care about consistent input models, APIs, and state management rather than optimizing one component at the expense of the others.

Interface-level permissions, server-side verification

Every Phiale component declares a manifest of its capabilities, for example column reordering or editing summaries. The developer decides whether a given instance exposes them, and whether a particular user sees them depends on that user’s permissions (RBAC). A component also declares which data it handles, for example Customers, so the ability to edit follows the user’s read, write and delete permissions for that data. Data from the server can carry attributes (ABAC) that block, for instance, editing a specific record; the backend computes the condition. Interface-level control is a convenience for the user: the backend always verifies permissions again. Work on this mechanism is in progress.

Code history and the purpose of the public repository

The public PhialeTech.Platform repository is a snapshot of one stage of development, not the current state of PhialeGis. The code history goes back to at least 15 December 2023; by 17 December 2023 it already contained early geometry work and the PhialeDrawBox component. The code remains proprietary; any binary packages and their terms will be published separately.

Project scope

  • Core independent of the UI framework
  • Neutral UniversalInput events and frontend adapters
  • Interface-level authorization (work in progress): a capability manifest per component, data permissions (read, write, delete) and attribute rules computed by the backend
  • PhialeDrawBox and DSL editor as separate ecosystem elements
  • PhialeGis and domain-specific DSL workflows