FluentUI: Zukünftige Richtung — Wdx als Inspirationsquelle
Zurück: FluentUI (Design-System-Bibliothek)
Status: Tier 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.
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 | Direktes PHP-Rendering per Helper-Methode (wie die bestehenden premiumnavyivory_render_*-Funktionen) |
#[WdxHandler]-gated Event-Dispatcher, AJAX-Rundreise, Patch-DSL | DokuWikis eigenes Action-Component-Hook-Modell + lib/exe/ajax.php-Endpunkte (bereits etabliertes Muster, z. B. wkacmenus AJAX-Endpunkte) |
wdx-runtime.js | Schlankes eigenes Vanilla-JS ohne Build-Schritt (wie js/nav-flyout.js/js/admin-rail.js) |
–wdx-*-Tokens | wkfluentuis eigenes –wk-*-System, siehe FluentUI: Design-Tokens |
| „Patch statt Full-Reload“ | Als Prinzip übernommen, aber als eigene kleine JS-Helper-Funktion — kein fremdes Protokoll |
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.