SQLite Data Studio: Bereichs-Spezifikation (normativ)

Studio-Doku: SQLite Data Studio · Design-System: FluentUI: Admin-Bereich (vertieft)

Status: normative Soll-Definition der Studio-Workbench (Plugin wksqliteds, vormals wvdsdwmsqlite; Admin-Bereich „Datenbank„). Diese Seite ist die verbindliche Grundlage der „Workbench Tier 1“-Umsetzung. Das Regionsmodell wird verlinkt, nicht dupliziert: Quelle der Wahrheit ist FluentUI: Admin-Bereich (vertieft) (Verhaltensregeln) bzw. FluentUI: Basic Layout (vertieft) (Regionen). Tier-Legende: [Live] = im Code umgesetzt · [T1] = „Workbench Tier 1„, wird implementiert · [T2] = nur spezifiziert (Widget-Katalog).

ADS-Belege sind gegen den Checkout {3rd}/azuredatastudio geprüft und als Quellpfade zitiert (rekonstruierte Mechanik, keine Code-Übernahme; ADS steht unter der Source-EULA — kein SVG-/Code-Transfer).

Normative Abweichungen der Studio-Workbench vom ADS-Vorbild, je mit Begründung.

1. Linke Aktivitätsleiste nur DW-Admin-Module [Live]. Die linke Rail hostet ausschließlich die ACL-gefilterten DokuWiki-Admin-Module (Muster admin-layout); das Studio legt dort nie eigene Aktionen ab. Begründung: In ADS hostet die Activity Bar die Tool-Viewlets selbst — im WvdS-Admin bleibt „welches Modul“ strikt getrennt von „was tue ich im Modul„, damit die Modul-Navigation über alle Werkzeuge gleich ist.
2. Rechte Modul-Rail für Studio-Aktionen [Live]. Modulnahe Dauer-Aktionen liegen in der rechten Modul-Rail .wk-shell-rail--right — Spezifikation layout / admin-layout, CSS-Primitive [Live] (wkfluentui@3307a0a). Alle vier Aktionen [Live]: Auxbar-Toggle, Query-Historie, Doku-Link (seit #821/#822) und seit dem Berechtigungsmodell (#825–#828, 2026-07-16) auch Berechtigungen (öffnet den Matrix-Dialog auf der Connections-Fläche). Begründung: ADS mischt Modul-Aktionen in Titelleisten/Viewlet-Header; die getrennte rechte Rail hält sie modulweit an einer Stelle.
3. Request-basierte Verbindungs-Semantik [Live]. Kein Connect/Disconnect/Cancel wie in ADS — jede Anfrage öffnet die Verbindung frisch (ConnectionManager::pdo(), Request-Cache). Die UI bietet stattdessen „Verbindung wählen“ und „Verbindung testen„; ein Cancel laufender Abfragen ergibt erst mit asynchronem Ausführen Sinn und ist [T2]. Begründung: DokuWiki ist Multi-Request ohne persistente Server-Sitzung je Verbindung — ein ADS-artiger Verbindungs-Lebenszyklus hätte kein Substrat.
4. Keybinding-Abweichungen [Live]. Ausführen = Strg+Enter statt ADS-F5 (F5 lädt im Browser neu). Vollständige Shortcut-Tabelle in Abschnitt 2. Begründung: Browser-Kollisionen; nur kollisionsfreie Tasten.
5. Kein SPA/Multi-Window [Live]. POST-Roundtrips + Progressive Enhancement statt Single-Page-App; kein zweites Fenster. Jede JS-Aufwertung hat einen No-JS-Fallback. Begründung: DokuWiki-Plugin-Architektur (act_dispatch, keine eigene JS-Grid-Engine); Barrierefreiheit by construction.
6. Farbsemantik Contract v3 [Live]. weiß = gewöhnliche Aktion (inkl. Speichern), blau = Sonderaktion (Export/Import), rot = destruktiv; in Toolbars DOM-Reihenfolge weiß→blau→rot (Contract v3) — nicht ADS-Blau als Haupt-CTA. Begründung: einheitlicher WvdS-Admin-Farbvertrag, Semantik hängt nie nur an der Farbe.
7. „Manage“-Dashboard = Overview-Hub [Live]. Statt ADS-Dashboard-Widgets ist die Tabellen-Übersicht (view/Overview.php) der discoverable Einstiegs-Hub; von dort führen Links in Structure/Browse/Export. Begründung: kein eigenes Dashboard-Framework in DokuWiki (Auflösung des Options-Plugins, siehe Admin-Bereich).

Geprüft gegen den ADS-Checkout {3rd}/azuredatastudio; Tier-Marker je Aktion. Farbspalte = Contract-v3-Semantik (w=weiß/neutral, b=blau/Sonder, r=rot/destruktiv).

Muster rowActions()/scripts/contextmenu.js (progressiv; re-triggert vorhandene Links).

Seit 2026-08-25 ist dies die Werkzeugleiste des Bereichs (.wkq-panebar), nicht die Befehlsleiste des Fensters — sie steht im Inhalt, weil ihre Bedienelemente das Formular des Editors ansprechen. Auf Telefonbreiten bricht sie um statt zu scrollen: ein am Rand abgeschnittenes Bedienelement ist keines, und die Anzeige für einen scrollbaren Streifen ist ein Rollbalken, den Berührungsgeräte im Ruhezustand nicht zeichnen.

Seit 2026-08-25 gehört die Region dem Host. Das Studio zeichnet keine eigene Befehlsleiste mehr; was modulweit ist, sind commandPalette-Beiträge und erscheint damit in der Befehlsleiste und in der durchsuchbaren Palette (Strg+Umschalt+P), ohne zweite Registrierung.

Vier Modulaktionen: Neue Abfrage · Abfrage-Historie · Berechtigungen — und keine Dokumentation. Die legt adminshell::commandsFor() ohnehin aus plugin.info.txt an; die erste Fassung dieser Liste erzeugte den Knopf ein zweites Mal.

Die Spalten unten nennen weiterhin, was der Bereich anbietet (.wkq-panebar, Abschnitt 2.3) — nicht mehr, was in der Fensterleiste steht.

• Titelleisten-Aufbau [Live]: Verbindungs-Dropdown, Neue Verbindung, Aktualisieren und Auxbar-Toggle [Live]; Objekt-Filter [T2]; Aufbau nach TreeView-Portal.
• Baumstufen je Backend [Live für SQLite, sonst T1]: SQLite flach (Verbindung → Tabellen/Views/Trigger/Routinen); MySQL mit Datenbank-Ebene; PgSQL/MSSQL mit Schema-Ebene; MS Access flach. Der Studio-eigene Ast „Routinen„ hängt unter der Verbindung (kein ADS-Konzept).
• Icon-Klassen-Schema [Live]: .wkq-node--{typ} mit typ ∈ connection/folder/table/view/trigger/routine/column/index/fk/pk; Status-Suffixe wkq-node-status--{readonly,unavailable,active}. Kein eigenes Datenbank-/Schema-Icon (SQLite bleibt flach, siehe Abschnitt 3).
• Icon-Herkunft [Live]: Eigenzeichnung als mask-image-SVG-Data-URIs in screen.css — keine ADS-SVGs (Source-EULA), kein Codicons-Fremdpaket eingebunden.

Belegung der Shell-Regionen im Studio. Regionen selbst: FluentUI: Basic Layout (vertieft) (nicht dupliziert).

Werkbank-Kontext statt zweiter Werkbank (seit 2026-08-25): das Studio zeichnet keine eigene Schale mehr. Es gibt seine Teile als Beiträge nach Contract v1 ab — Objektbaum in sidebar, Objekteigenschaften in auxbar, Ergebnisse in bottomPanel, Modulaktionen in commandPalette — und der Host baut das Raster darum.

Der Vorweg — getShellRegions(), bis dahin von 2026-07-18 an in Gebrauch — ist entfallen, und sein Preis war höher als die Verschachtelung, die er behob: action_plugin_wkfluentui_adminworkbench::compose() prüft als erstes ownsItsShell() und kehrt bei true zurück. Damit lief auch windowRegions() nie — und dort entstehen Aktivitätsleiste und Modulreiter. Gemessen vor der Umstellung:

Wer im Studio stand, hatte keinen Weg zu einem anderen Modul ausser über den Zurück-Knopf. Nach der Umstellung trägt der Bildschirm dieselben Werte wie seine Nachbarn.

Zweite Folge, die der alte Weg mitbrachte: Explorer und Schiene erreichten die Schale über wkbizway/inc/wiki-shell.php — einen vorlagenspezifischen Weg. Unter jeder anderen Vorlage war der Objektbaum schlicht weg. Beiträge kennen diese Abhängigkeit nicht.

Was im Inhalt bleibt, und warum es keine zweite Leiste ist: die Werkzeugleiste des Editors (.wkq-panebar — Verbindung, Ausführen, Syntax prüfen, Abfrageplan) und die Bereichs-Fusszeile (.wkq-panestatus). Beide sprechen den Bereich an, nicht das Fenster; der Verbindungswähler ist ein <select> und Ausführen sendet das Formular des Editors — keines von beiden ist als kind:action ausdrückbar. Azure Data Studio zieht dieselbe Linie: die Werkzeugleiste eines Abfragereiters ist nicht die Befehlsleiste des Fensters.

Drei benannte Lücken stehen in docs/view-layer.md des Pakets: die Reiterleiste für Arbeitsobjekte (adminshell::tabStripHtml() löst jeden Namen mit plugin_load(admin, …) auf und kann daher nur Module benennen), die Fenster-Statuszeile und ein Überlaufmenü der geteilten Werkzeugleiste. Alle drei gehören in den Host; ein fehlendes Bedienelement liest sich sonst wie eine Entwurfsentscheidung.

WebView statt Wiki-Karte (seit 2026-07-18): die Studio-Fläche liegt seither direkt in <main>, ohne den .premiumnavyivory-wiki-card-Dokumentrahmen (Hintergrund/Schatten/ Padding) — Details: admin-layout, „WebView statt Dokument-Karte".

EXPLAIN QUERY PLAN ist aus dem Editor in einer Aktion erreichbar und öffnet als Reiter des unteren Panels. Eigene Aktion und nicht Teil von Ausführen: einen Plan fordert man gerade dann an, wenn das Ausführen zu lange dauert.

Gezeichnet wird, was SQLite liefert, und nichts darüber hinaus — vier Spalten, also ein Elternverweis und ein Satz. Es gibt keine Kosten, keine Zeilenschätzungen und keine Zeiten; einen gewichteten Graphen zu zeichnen hiesse, Zahlen zu erfinden, und eine erfundene Zahl ist von einer gemessenen nicht zu unterscheiden. Hervorgehoben wird die eine Unterscheidung, die wirklich in den Daten steckt:

Die dritte Marke ist am ersten gemessenen Plan entstanden: SCAN c USING INDEX idx_comments_created beginnt mit SCAN, liest aber den Index — „Ganze Tabelle“ wäre dort falsch gewesen. Der rowid wird ausdrücklich nicht als Index gemeldet; er ist keiner, den jemand anlegen oder löschen könnte. Die Rohausgabe bleibt aufklappbar daneben: eine Deutung, die man nicht gegen ihre Quelle halten kann, ist eine Behauptung.

Der Plan läuft durch dieselbe Einstufung wie jede Abfrage. Beschreibt die Anweisung einen Schreibvorgang, wird write verlangt — wer nicht schreiben darf, darf auch den Plan eines Schreibvorgangs nicht lernen. Auf anderen Systemen als SQLite erscheint der Knopf gar nicht, statt eine Fehlmeldung anzubieten.

Ein Zweig wird gebaut, wenn die Adresse ihn nennt (treeopen), oder wenn er die Tabelle ist, die der Bildschirm ohnehin zeigt. Vorher kostete jede Tabelle vier Introspektionsabfragen und jeder Routinenknoten ein geladenes Manifest — für Zweige, die geschlossen rendern.

Die Angabe steht in der Adresse und nicht in einem Skript: ein Zweig, der sich nur mit JavaScript öffnet, hat kein Lesezeichen, keinen Zurück-Knopf und keine Historie. Der Aufklapp-Verweis trägt den Bildschirm mit, auf dem er geklickt wurde — Aufklappen ist keine Navigation. Die Zählungen bleiben in den Ordnerbeschriftungen: listRoutines() ist ein Verzeichnislisting und billig, teuer war das Laden der Manifeste.

Der Wartungsbildschirm führt je Aktion Bedeutung · Risiko · erwartete Dauer · Sperrwirkung. Zur Dauer steht dort keine Sekundenzahl: SQLite liefert für keine dieser Aktionen eine Schätzung, und dieses Paket misst vorher keine. Bekannt ist die Dateigrösse und dass jede Aktion linear darin ist — also nennt die Spalte, womit die Dauer wächst, und dazu die aktuelle Grösse. Die Sperrwirkung ist SQLites dokumentiertes Verhalten, keine Messung dieser Installation.

Die Auxbar folgt der Auswahl (Click-to-Reload [Live] + auswahl-folgend [Live], Client-Vertrag admin-layout).

Bausteine drawer()/modal() (FluentUI: Öffentliche Helper-API).

Server-erzwungenes Rollenmodell zusätzlich zum Superuser-Gate. Heute [Live]: Zugriff nur Superuser + dbadmin_readonly als globaler Not-Aus. Ziel [T1]: fein granulare Policy.

• Fähigkeiten: use (Bereich betreten) · query (lesen/SQL-Konsole lesend) · write (Datenänderung) · design (DDL/Table Designer) · export · admin (Verbindungen/Policy verwalten).
• Zeilen: DW-Gruppen/Benutzer in acl.auth.php-Notation (@gruppe bzw. benutzer).
• Scope: global und je Verbindung; die spezifischere Regel gewinnt (Verbindung schlägt global) — analog zur DokuWiki-ACL-Spezifität.
• Persistenz: conf/wksqliteds.policy.json (io_saveFile, atomar; kein Secret enthalten).
• Enforcement: serverseitig in einem PolicyGate vor jeder Aktion (nicht nur UI-Ausblendung) — Default-Deny; die UI blendet zusätzlich aus, ist aber nie autoritativ.
• Default: nur Superuser (Rückwärtskompatibilität; ohne Policy-Datei verhält sich das Studio wie heute).
• Not-Aus: dbadmin_readonly=1 übersteuert jede write/design-Fähigkeit — die SQL-Konsole lässt dann nur lesende Anweisungen zu (Statement-Vollanalyse + SQLite PRAGMA query_only).
• Abgrenzung: Policy regelt den Studio-Zugriff, nicht die Seiten-ACL — eine Person mit Seiten-Leserecht auf die Doku hat dadurch keinen Studio-Zugriff.

Beispiel (acl.auth.php-Notation, illustrativ):

# global
@wvdse   use,query,export
# je Verbindung "prod" (spezifischer -> gewinnt)
prod:@wvdse   use,query          # auf prod nur lesen, kein write/design

Auslöser: Nutzer-Rückmeldung 2026-07-16 anhand eines Screenshots der Connections-Fläche — berechtigter Befund, kein Missverständnis. Geltungsbereich: ausschließlich die eigenen wksqliteds-Screens; Fremd-Plugins werden weiterhin nur innerhalb der Shell eingebunden (Inline-Dialog-Muster, Abschnitt 6/admin-layout), niemals selbst verändert.

Befund (Ist-Zustand, code-geprüft): dataGrid() — der echte, JS-gestützte Grid-Baustein aus wkfluentui (Sortierung, Paging, Auswahl, konsistente Fluent-Optik) — wird im gesamten Studio nur an einer Stelle benutzt: dbadmin/ResultGrid.php (Datenbrowser + Workbench-Ergebnisraster). Drei Bildschirme rendern stattdessen einfache Wiki-Tabellen (<table class="inline wkq-full">, admin.php Zeilen ~580/~1190/~1297): Verbindungen-Liste, Routinen-Liste sowie — nicht durch admin.php selbst, sondern in view/Overview.php — die Tabellen-Übersicht; die vier Table-Designer-Register (Columns/Indexes/Foreign-Keys/Triggers) nutzen ebenfalls schlichte Tabellen statt dataGrid(). Der Fluent-Formularmetrik-CSS-Vertrag (Label-Achse, Fokusring, 3px-Statusbalken) greift auf diesen Tabellen bereits — visuell teilweise Fluent, aber ohne Sortier-/Auswahl-Interaktion und ohne die einheitliche Grid-Optik, die dataGrid() andernorts liefert. Zusätzlich rendert jede Admin-Seite innerhalb DokuWikis normaler Seitenhülle (Titelzeile, Karten-Innenabstand) — Standardverhalten für jedes AdminPlugin dieser Instanz, keine Studio-spezifische Unterlassung, aber sichtbar der Grund für den „Wiki-Dokument-auf-Karte„-Eindruck.

Zielzustand:

1. Grid-Konsistenz: alle listenartigen Studio-Screens (Verbindungen, Routinen, Tabellen-Übersicht, Table-Designer-Register) wechseln von der schlichten Wiki-Tabelle auf dataGrid() — mindestens Spaltensortierung und einheitliche Optik; Mehrfachauswahl nur dort, wo eine sinnvolle Massenaktion existiert (Routinen/Verbindungen-Löschen ließe sich als Massenaktion anbieten, ist aber kein Muss für die erste Stufe).
2. Viewport-Fit als verbindliche Regel für Studio-Screens: admin-layout.txt führt Fensterhöhen-Anpassung nur als Richtlinie („bevorzugt, keine harte Regel“); für die Studio-Screens mit eigener Statusbar (alle fünf Views) wird sie hier auf verbindlich gehoben — deckt sich mit der dortigen Begründung „lohnt sich, wo eine Shell mit eigener Statusbar/Sidebar arbeitet„.
3. Doppelte Titelzeile bereinigen: die Connections-Fläche zeigt „SQLite Data Studio“ derzeit zweimal (Plugin-Seitentitel und Bereichs-Überschrift) — ein Redundanzbefund aus demselben Screenshot, unabhängig von der Grid-Frage, hier als offener Punkt mitgeführt.

Abgrenzung: dies ändert nichts an der Wiki-Seitenhülle selbst (Topbar/Footer/Karten- Rahmen bleiben, wie bei jedem AdminPlugin dieser Instanz) — das wäre ein Eingriff auf Template-/Core-Ebene und damit außerhalb dessen, was ein einzelnes Plugin verantwortet. „Anwendungs-Optik„ bedeutet hier: dichteres, grid-konsistentes Modul-Innenleben innerhalb der bestehenden Shell-Regionen, nicht das Verschwindenlassen der Seitenhülle.

Entscheidungsvorlage (Capability → Tier → Aufwand → Abhängigkeiten):

Offene Fragen:

1. Sollen Verbindungen/Routinen eine Mehrfachauswahl mit Massenlöschen bekommen (analog Browse), oder bleibt Einzel-Löschen ausreichend?
2. Table-Designer „Columns“-Register hat inline editierbare Formularfelder je Zeile — dataGrid() ist laut eigenem Vertrag (dialog-katalog) ein reines Anzeige-Widget; eine Migration braucht entweder eine erweiterte dataGrid()-Editierfähigkeit oder bleibt bei declarativeTable() als Grid-Alternative für diesen einen Fall.

Auslöser: Nutzer-Abgleich 2026-07-17 gegen die WDX-Referenzanwendung (AMED-WIS, WdxWorkbenchLayout: Titlebar · Command-Bar · Activity-Bar · Sidebar · Editor · Panel · Statusbar) — dort liegt jede Arbeitsfläche innerhalb der Workbench-Regionen; im Studio galt das nach Abschnitt 8 zwar für die Listen-Screens, aber noch nicht für die Formular-/Detail-Screens.

Befund (Ist-Zustand vor dieser Stufe, code-geprüft): „Verbindung bearbeiten„ (renderConnEdit()), „Routine bearbeiten“ (renderRoutineEdit()) und der Routinen-Test rendern als Wiki-Dokumente: <p>« zurück</p>-Absatz statt Command-Bar, Formular als <table class="inline"> statt propertyGrid()-Formularmetrik, keine Statusbar, kein Shell-Grid — der einzige Screen-Typ des Studios, der noch vollständig außerhalb des Regionsmodells lag.

Zielzustand (normativ):

1. Jeder eigene Studio-Screen — auch Formular-/Detail-Screens — rendert die drei Grundregionen: Command-Bar (.wk-shell-commandbar), Shell-Grid (.wkq-shell--flat genügt für Formulare) und Statusbar (dbadmin/Statusbar.php, links der Datensatz-Kontext, z. B. default:close_pruefung).
2. Navigation und Datensatz-Aktionen in der Command-Bar nach Contract v3: „« Zurück zur Liste„ (weiß, Link), „Verbindung testen“ (blau, nur bestehende Datensätze), „Löschen„ (rot, nur bestehende Datensätze; läuft über denselben confirmGuard()-Zweischritt wie die Listen-Aktion) — der Dokument-Absatz „« zurück“ entfällt.
3. Formularmetrik über propertyGrid() (Edit-Modus, plainFieldRows()-Fallback ohne wkfluentui) statt <table class="inline"> — dieselbe Label-Achse wie Routinen-Eigenschaften-Tab und Auxbar.
4. Content-Überschriften als Pane-Header: direkte <h2>-Kinder von .wk-shell-content rendern in ADS-Viewlet-Optik (kompakt, Versalien, gedämpft) statt als Dokument-Überschrift — Semantik/A11y bleiben erhalten, nur die Optik wechselt von „Dokument„ zu „Werkzeugfläche“.

Abgrenzung (revidiert 2026-07-17, „fill the gaps„-Feature): DokuWikis msg()-Hinweisbanner bleiben der Kanal für Vollseiten-POST-Ergebnisse (Core-Verhalten oberhalb des Moduls); asynchrone JS-Rückmeldungen (Auxbar-Transportfehler, Massenaktionen, Präferenz-Wechsel) laufen seither über den Toast-Host wkToast() aus wkfluentui — die frühere „kein Toast-Host“-DW-Ausnahme ist damit aufgehoben (admin-layout, Regel „Toast-Host„). Der Bereichs-Pivot (Verbindungen/Datenbank/Routinen) bleibt oberhalb der Command-Bar (die linke Aktivitätsleiste gehört laut Abschnitt 1 den DW-Admin-Modulen, nicht den Studio-Bereichen).

• Keine Single-Page-App, kein zweites Browser-Fenster.
• Keine neuen DB-Treiber über die bestehenden (SQLite/MySQL/PgSQL/SQLSRV/Access-ODBC) hinaus.
• Keine Änderungen an Fremd-Plugins — nur Einbindung innerhalb der Shell (Abschnitt 6).

• FluentUI: Admin-Bereich (vertieft) — Quelle der Wahrheit: Admin-Verhaltensregeln
• FluentUI: Basic Layout (vertieft) — Regionen/wk-shell-*-Vokabular
• FluentUI: Basis-Widget-Katalog — Widget-Katalog inkl. [T2]-Bausteine
• Styles-Contract (--wk-*) — Contract v3 (Farbsemantik/Tokens)
• SQLite Data Studio — Studio-Produktdoku (Wegweiser, Routinen/Verbindungen/API/How-to)

Verifiziert gegen: wk-dw-sqliteds-plugin@24b83d2 (Branch feature/454-workbench-grid: Grid-Migration auf das generische .wk-workbench aus wkfluentui@274a7d9, Statusbar-Prioritäten, Sash statt CSS-resize, Workbench-Kontexte; davor @641e8cf main; enthält zusätzlich zu Rename-Migration, Struktur-Härtung, „Workbench Tier 1“ und Berechtigungsmodell Stufe 1+2 jetzt auch: Fenster-Ebene-Komposition #899, Formular-Screens in Shell-Regionen Abschnitt 8.1 sowie die Studio-[T2]-Verdrahtung #881 — Editor-Tabs, Command-Palette, Objektbaum-Filter und Results-Maximieren sind damit [Live]); rechte Modul-Rail wkfluentui@3307a0a (gemergt). Verbleibend [T1]: „Neue Tabelle„ im Verbindungs-Knotenmenü (Abschnitt 2.2); verbleibend [T2]: Table-Designer-Grid-Migration (Abschnitt 8, offene Frage editierbare Zellen) und die übrigen in Abschnitt 9 nicht genannten, explizit markierten Positionen. Status-Legende: [Live] umgesetzt · [T1] Workbench Tier 1 (in Umsetzung) · [T2] nur spezifiziert.