FluentUI: Basic Layout (vertieft)

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

Status: Gemischt — je Zeile der Parts-Tabelle unten vermerkt. Sidebar/Content/AuxiliaryBar/Statusbar sind Tier 1 (echter Konsument: wksqlitedss .wkq-shell-Grid). Titlebar/Activity Bar bleiben Tier 2, aber aus einem anderen Grund als „noch nicht gebaut“: sie sind bereits geerbt von der Wiki-Shell der Hausvorlage wkbizway (Topbar/Action Rail, siehe Wiki-Area-Shell) — wksqliteds baut sie bewusst nicht neu. Panel/Banner bleiben Tier 2, ohne aktuellen Konsumenten.

Quelle: Azure Data Studio (https://github.com/microsoft/azuredatastudio, ein VSCode-Fork — Layout-Mechanik ist zwischen beiden identisch, daher gilt dieselbe Quelle auch für https://github.com/microsoft/vscode). Layout-Engine: src/vs/workbench/browser/layout.ts (arrangeMiddleSectionNodes(), createGridDescriptor()), Parts-Vokabular: layoutService.ts:21-30 (Parts-Enum).

Skizze des ADS-Referenzlayouts (identisch auf der start-Seite):

Status: [Live] — beschreibt bestehendes, bereits umgesetztes Verhalten (premium-navy-ivory, inc/wiki-shell.php bzw. main.php), keine neue Spezifikation.

Abgrenzung zu Banner: Breadcrumbs sind eine eigene Region, keine Verwendung von .wk-shell-banner — jene Klasse bleibt ausschließlich der schließbaren Hinweisleiste vorbehalten (siehe Parts-Tabelle oben, Zeile BannerPart, sowie admin-layout, Abschnitt „Verbindliche UX-Regeln", Abgrenzung Banner).

Die Breadcrumb-Leiste zeigt den Navigationspfad der aktuellen Seite (DokuWiki-Kernfunktionen tpl_youarehere()/tpl_breadcrumbs(), gesteuert über die Admin-Optionen $conf['youarehere']/$conf['breadcrumbs']) als eigene, dezente Leiste in voller Breite direkt unter der Topbar.

• Position: eigene volle-Breite-Leiste zwischen Topbar (</header>) und Shell-Grid (.premiumnavyivory-wiki-shell) — Banner-POSITION, aber eigene Region; nicht in der Content-Karte (dort lag sie bis zur Verschiebung, die Karte beginnt seither direkt mit der Seiten-Überschrift) und nicht im .wk-shell-banner.
• Träger: .premiumnavyivory-wiki-crumbbar (Wiki-Areaprofil, inc/wiki-shell.php; Optik in css/area-wiki.css: gedämpfte 0.8em-Schrift auf Mat-Ton, Haarlinien-Unterkante). Site-Areaprofil unverändert: .breadcrumbs (main.php, innerhalb .page-heading-container).
• Admin-Bereich: vollständig ausgeblendet ($ACT !== 'admin'-Bedingung) — ein Admin-Bildschirm übernimmt $ID von der aufrufenden Seite (DokuWiki-Kern, inc/Menu/Item/AbstractItem.php), Breadcrumbs würden also den Pfad einer fremden Seite zeigen statt des tatsächlich betrachteten Admin-Bildschirms. Keine gesonderte Admin-Breadcrumb-Region vorgesehen.

Status: [Live] — diese Beschreibung ist die verbindliche Spezifikation; das CSS-Primitive liefert die Region, die Verdrahtung in ein Modul erfolgt im Feature „Workbench Tier 1„. Die Regionsdefinition wohnt hier (Eigentums-Regel „eine besitzende Seite je Aussage“); die UX-/Verhaltensregeln stehen in admin-layout.

Die rechte Modul-Rail (.wk-shell-rail--right) ist eine schmale, senkrechte Icon-Leiste für die modulnahen Dauer-Aktionen des gerade aktiven Admin-Moduls (im Studio z. B. Auxbar ein-/ausblenden, Query-Historie, Berechtigungen, Doku-Link). Sie ist das rechte Gegenstück zur linken Aktivitätsleiste (.wk-shell-rail), die ausschließlich der ACL-gefilterten Modul-Auswahl vorbehalten bleibt — nie Modul-Aktionen (DokuWiki-Ausnahme gegenüber Azure Data Studio, wo die Activity Bar die Tool-Viewlets selbst hostet).

• Grid-Platz: rechts außen, feste Breite 52px (Token --wk-shell-rail-w), volle Höhe der Spaltenzeile zwischen Command-Bar-Zeile und Statusbar. Wie alle .wk-shell-*-Primitives liefert die Klasse nur Fläche/Rahmen/Metrik — die Grid-Spur (grid-template-columns/grid-template-areas) setzt das konsumierende Modul in seiner lokalen Shell-Komposition (Muster wie wksqlitedss .wkq-shell, siehe Modifikator-Tabelle oben). Die neue Klasse aktiviert nur die Region; Bestands-Layouts ohne sie bleiben unverändert (additiv).
• Verhältnis zur Auxbar: Die Rail liegt außen neben der Auxbar — beide sind getrennte Regionen mit getrennter Aufgabe. Die Auxbar (.wk-shell-auxbar) zeigt Inhalt (Eigenschaften/Bereiche der Auswahl), die Rail zeigt Aktions-Schalter (u. a. den Auxbar-Toggle selbst). Reihenfolge der Spaltenzeile: Sidebar · Content · Auxbar · Rail(rechts).
• Verhalten unter 1024px: Die Rail entfällt (die Spur kollabiert); ihre Aktionen wandern in die Overflow-Gruppe („…„) der Command-Bar. Das folgt denselben Breakpoints wie Sidebar/Auxbar-Kollaps (siehe wksqliteds/screen.css-Media-Queries) und ist Sache der konsumierenden Grid-Komposition, nicht des Primitives.
• No-JS-Fallback: Rail-Aktionen sind gewöhnliche Links/Buttons — der Auxbar-Toggle ist ein Link auf dieselbe Seite mit gesetztem Query-Parameter, „Query-Historie“/„Berechtigungen„ öffnen ihre jeweilige Seite/ihren Dialog serverseitig. JavaScript wertet sie nur auf (Toggle ohne Reload, aktiver Zustand); ohne JavaScript bleibt jede Aktion erreichbar.
• A11y-Kurzform (Details in admin-layout): Icon-Buttons 32×32 in der 52px-Rail, Tooltip + aria-label, Roving-Tabindex, aktiver Zustand für Toggles (aria-pressed).

• Activity Bar / Sidebar: Object Explorer / Connections-Tree (statt generischem Datei-Explorer)
• Editor-Bereich: Query-Editor + Results-Grid, SlickGrid-basiert (src/sql/base/browser/ui/table/table.ts), sowie Table Designer als bester Fund für „Formular+Datengrid-Hybrid“ (src/sql/workbench/browser/designer/, .components-grid { display:grid; grid-template-columns: max-content 1fr; })
• Panel: in ADS z. B. Query-Results/Messages/Query-Plan-Tabs
• Auxiliary Bar: Properties-Panel (kontextsensitive Eigenschaften des ausgewählten Objekts)
• Statusbar: Server-/Datenbank-/Zeilenzahl-Anzeige statt Git-Branch/Encoding
• Overlay (kein Grid-Part): Modal-Basisklasse (src/sql/workbench/browser/modal/modal.ts) — zwei Formen: zentrierter .modal.normal-dialog (640px) vs. ADS-eigener .modal.flyout-dialog (slides von rechts, narrow/medium/wide = 500/800/1200px). ADS bevorzugt Flyouts für datenlastige Formulare (Connection-, Restore-, Firewall-Rule-Dialog).

VSCode/ADS nutzen eine SerializableGrid (rekursiver Sash-basierter SplitView-Baum, JS-verwaltete Pixelgrößen, src/vs/base/browser/ui/grid/grid.ts) statt CSS Grid/Flexbox. Positionswechsel (Sidebar links/rechts, Panel oben/unten/links/rechts) sind reine Grid-Node-Verschiebungen (layout.ts:1972-1998), keine unterschiedlichen CSS-Pfade.

Für ein DokuWiki-Plugin ohne eigene JS-Grid-Engine ist der realistische Gegenwert ein CSS-Grid/Flexbox-Template (feste Zeilen für Titelleiste/Statusleiste, feste-oder-resizable Spalten für Rail/Sidebar/Panel) statt Sash-Dragging nachzubauen — die Regionsvokabular- und CSS-Variablen-Namenskonvention (–vscode-<part>.<property> → –wk-shell-<part>- <property>) ist direkt übernehmbar, unabhängig davon, ob resizable Sashes je gebaut werden.

Die generischen .wk-shell-*-Primitives dieses Plugins liefern nur Hintergrund/Border/Spacing je Region — die Grid-Komposition (welche Regionen in welcher Anordnung) ist bewusst Sache des konsumierenden Moduls. Die folgenden Modifikatoren sind darum wksqliteds-lokale Kompositionen auf dessen .wkq-shell-Grid-Container (wksqliteds/screen.css, Zeilen 353/362), keine wkfluentui-Klassen. Ein anderes Modul definiert seine eigenen Kompositions-Modifikatoren nach demselben Muster.

Zustands-/Sichtbarkeits-Klassen nach VSCode-Vorbild (nosidebar u. a.) sind davon getrennt — siehe den folgenden Abschnitt.

VSCode toggelt globale Layout-Zustände über CSS-Klassen auf der Wurzel (LayoutClasses-Enum, layout.ts:95-106): nosidebar, nomaineditorarea, nopanel, noauxiliarybar, nostatusbar, fullscreen, maximized. Ein DW-natives Shell-Modul würde denselben Ansatz nutzen (z. B. .wk-shell.no-sidebar statt einer JS-Sichtbarkeits-API).

Verifiziert gegen: wkfluentui@a477094, wk-dw-msqlite-plugin@240c064. Rechte Modul-Rail (Regionsdefinition, [Live]): CSS-Primitive wkfluentui@a477094.