FluentUI: Zukünftige Richtung — Schema-gestützte Formular-Seiten
Zurück: FluentUI (Design-System-Bibliothek)
Status: umgesetzt — per Nutzer-Entscheid als
Option (a), integriert in wkfluentui statt als eigenes Plugin. Quelle der Wahrheit
für den implementierten Vertrag: FluentUI: Schema-gestützte Formular-Seiten. Diese Seite
bleibt als Entscheidungsgrundlage/Optionsvergleich erhalten (historischer Kontext der
Architekturentscheidung).
Ausgangsidee
Statt „Create new Page“ ein Menü, das strukturierte Seitentypen anbietet (Beispiel: „Create BUG WI“) — Auswahl öffnet einen Formular-Dialog, dessen Felder durch eine Schema-Definition (Pflicht- felder, Typen, Auswahllisten) erzwungen werden, statt Freitext zuzulassen. Die entstehende DokuWiki-Seite wird als „Formular“ gerendert und über eigene CSS-Chrome editiert, nicht über den normalen Wiki-Editor.
Verwandtschaft zu Wdx' Page-Contract
Konzeptionell verwandt mit Wdx' Page-Contract-Modell (siehe FluentUI: Zukünftige Richtung — Wdx als Inspirationsquelle): dort ist jede Seite eine Logik-Datei + eine logikfreie, deklarative Designer-Datei + optional eine DTO-Datei, geprüft durch einen statischen Gate. Gemäß der Entscheidung auf der Wdx-Seite wird diese Idee übernommen, die Implementierung jedoch nicht — kein Composer-/Laufzeit-Import von Wdx.
Optionen (ohne Wdx-Laufzeit-Abhängigkeit)
| Option | Beschreibung | Bewertung |
|---|---|---|
| (a) DW-natives Schema-Formular-Plugin (empfohlen) | Neue Syntax-/Action-Komponente (in wkfluentui oder einem eigenen kleinen Plugin), die eine YAML- oder XML-Schema-Definition pro Seiten-„Typ“ liest, daraus ein Formular mit wkfluentuis eigenen Widget-Bausteinen (siehe FluentUI: Basis-Widget-Katalog) rendert, bei Submit serverseitig über einen Action-Hook validiert und das Ergebnis als reguläre DokuWiki-Seite (Wiki-Syntax + Metadaten-Block) speichert | Kein Fremd-Framework, volle Kontrolle über Rendering/Validierung, nutzt DokuWikis eigene Mechanismen (Action-Hooks, ACL, checkSecurityToken()) direkt |
(b) DokuWikis struct-Plugin (aktuell nicht installiert) um Formular-UI erweitern | Nativer DokuWiki-Weg über ein etabliertes Fremd-Plugin | Geringerer Eigenentwicklungsaufwand, aber weniger Kontrolle über das Fluent-Look-and-Feel; zusätzliche Fremd-Plugin-Abhängigkeit |
| © 1:1-Nachbau von Wdx' XML/YAML-Designer-Datei-Mechanismus als eigenständiges Plugin | Vollständige Neuimplementierung des Page-Contract-Konzepts | Nicht empfohlen als Erstschritt — deutlich größerer Umfang als (a) |
Empfehlung
Option (a), sobald diese Initiative separat beauftragt wird — DW-artig implementiert, Wdx nur als Ideen-Vorbild (Trennung Logik/Deklaration, erzwungene Feld-Validierung), nicht als Laufzeit-Abhängigkeit. Voraussetzung für eine belastbare Umfangsschätzung: ein konkretes Beispiel-Seitentyp (z. B. „BUG WI“) mit vollständiger Feldliste, nicht nur das generische Konzept.