FluentUI: Zukünftige Richtung – Wdx als Inspirationsquelle

Zurück: FluentUI (Design-System-Bibliothek)

Warum WvdS.Wdx als Vorbild dient, aber nicht als Abhängigkeit: was das Paket ist, was daran überzeugt und warum es zur Laufzeit trotzdem nicht eingebunden wird.

Status: Stufe 2 – vollständig spezifiziert, nicht Teil der aktuellen Umsetzung, keine Laufzeit-Abhängigkeit von WvdS.Wdx. Diese Seite dokumentiert eine bewusste Architekturentscheidung, damit sie nicht erneut zur Diskussion steht, ohne die Begründung zu kennen.

Korrektur vom 03.11.2026: Die Ablehnung des Deklarationsbaums gilt nicht mehr. Bildschirme werden als Beschreibung geführt – Daten, die wkfluentui zeichnet –, die Logik bleibt PHP und wird über Namen gebunden. Wo diese Trennung in PHP endet, steht je Kriterium in der Entscheidung docs/adr/0002-screens-are-descriptions.md des Plugins. Nicht geändert hat sich: Die Laufzeit von Wdx wird nicht eingebunden; die Gründe unten gelten dafür weiter.

Was WvdS.Wdx tatsächlich ist

Eigenständiges, DokuWiki-fremdes Composer-Paket-Bündel außerhalb dieses Repositories (8 Pakete, PHP ≥8.3, Lizenz „proprietary“). Reifegrad-Stand (verifiziert, Commits 2026-07-06 bis 2026-07-08, 61 Commits in 3 Tagen – ein sehr junges, schnell bewegtes Ziel):

Paket	Rolle	Reifegrad
`WvdS.Wdx.Core`	Basishierarchie, `WdxComponent`, Enums, `WdxExpr` (nur `permission()` konkret)	stabil, klein
`WvdS.Wdx.Ui`	Fluent-Builder-Controls, 1:1 nach DevExpress-Blazor-API (`Dx` → `Wdx`)	funktional
`WvdS.Wdx.Runtime`	Echter SSR-Renderer (deskriptor-getrieben, 104 registrierte Komponententypen), Event-Dispatch, Patch-DSL	funktionierend, Ende-zu-Ende verdrahtet
`WvdS.Wdx.Pwa`	HTML-Dokument-Host, Manifest/Service-Worker-Compiler, Client-Runtime (`wdx-runtime.js`, 575 Zeilen)	funktionierend, laut eigenem Header ein „seed“ für einen künftigen Generator
`WvdS.Wdx.Theming`	`–wdx-*`-Token-System	verdrahtet
`WvdS.Wdx.Files`, `WvdS.Wdx.Reporting`	Datei-Explorer, Berichtsmodell	vorhanden
Bereits gebaut, direkt relevant	`WdxWorkbenchLayout`, `WdxTitleBar`	deckt sich mit FluentUI: Basic Layout (vertieft)

Event-/Rendering-Modell: Deklaration → SSR-Rendering mit Hydrations-Markern → Client hydratisiert → AJAX-Event-Rundreise zu einem attribut-gesicherten Server-Handler → Patch-Liste → gezielte DOM-Aktualisierung (kein Full-Page-Reload). Konzeptionell an DevExpress Blazor Server angelehnt, aber PHP-SSR + Vanilla-JS-Hydration statt SignalR/WASM.

Entscheidung: Inspiration ja, Laufzeit-Integration nein

wkfluentui bindet WvdS.Wdx nicht als Laufzeit-Abhängigkeit ein: kein Composer-/ PSR-4-Bridge, kein vendor/-Ordner, kein Hosten von WvdS.Wdx.Runtime/WvdS.Wdx.Pwa innerhalb von DokuWiki. Wdx (und dahinter DevExpress Blazor) dient ausschließlich als Vokabular- und Verhaltens-Inspiration. Die tatsächliche Umsetzung erfolgt DW-artig:

Wdx/DevExpress-Konzept	DW-native Entsprechung in `wkfluentui`
`WdxComponent`-Deklarationsbaum + Deskriptor-Renderer	Bildschirmbeschreibung als Daten (XML wie `workbench.xml` und die Formularschemas), gezeichnet vom Renderer im Kern von `wkfluentui` – ohne Wdx-Pakete
`#[WdxHandler]`-gated Event-Dispatcher, AJAX-Rundreise, Patch-DSL	Befehle nach Namen deklariert; ein Verteiler im Kern prüft Methode, Sicherheitstoken und ACL und ruft den gleichnamigen Handler. Er hängt sich in DokuWikis Action-Pipeline ein, statt sie zu ersetzen
`wdx-runtime.js`	Schlankes eigenes Vanilla-JS ohne Build-Schritt (wie `js/nav-flyout.js`/`js/admin-rail.js`)
`–wdx-*`-Tokens	`wkfluentui`s eigenes `–wk-*`-System, siehe FluentUI: Design-Tokens
„Patch statt Full-Reload“	Ein Bereich wird auf dem Server aus derselben Beschreibung neu gezeichnet und von einer kleinen Kernfunktion eingesetzt – kein Patch-Protokoll, kein Bildschirmzustand auf dem Server

Warum diese Entscheidung: Composer/PSR-4 in einem DokuWiki-Plugin ist unüblich für dieses Ökosystem (Deploy-Komplexität, exFAT-Stick-Kompatibilität der vendor/-Dateimenge – bekannte exFAT-I/O-Fallstricke dieser Instanz); die Lizenz ist als „proprietary“ deklariert und müsste vor jeder Einbindung explizit geklärt werden; Session-/CSRF-Bridging zwischen Wdx' eigenem Host-Modell und DokuWikis Sicherheitsmodell (checkSecurityToken(), ACL, Session-Timing) wäre ein eigener, ungelöster Adapter; und Wdx ist mit 61 Commits in 3 Tagen ein bewegliches Ziel ohne stabile Version. Ein reines PHP/CSS/Vanilla-JS-Plugin ohne Fremd-Framework-Abhängigkeit ist konsistent mit jedem anderen wvds*-Plugin in dieser Codebase und trägt keines dieser Risiken.