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 „Abfragen-Assistent“). Diese Seite ist die verbindliche Grundlage der Umsetzung der Workbench-Stufe 1. Das Regionsmodell wird verlinkt, nicht dupliziert: Quelle der Wahrheit ist FluentUI: Admin-Bereich (vertieft) (Verhaltensregeln) bzw. FluentUI: Basic Layout (vertieft) (Regionen). Legende der Stufen: [Live] = im Code umgesetzt · [S1] = Workbench-Stufe 1, wird implementiert · [S2] = nur spezifiziert (Widget-Katalog).

ADS-Belege sind als Quellpfade des Azure-Data-Studio-Quelltexts 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. Modulbefehle sind Beiträge zur Befehlspalette, nicht die rechte Modul-Rail [Live]. Das Studio gibt genau einen modulweiten Befehl ab: „Neue Abfrage“. Der Host zeichnet ihn als Hauptschaltfläche der Befehlsleiste und bietet ihn in der Befehlspalette an. „Abfrage-Historie“ und „Berechtigungen“ stehen seit 25.08.2026 im Menü „Aktionen“ der Verbindung im Objekt-Explorer; „Dokumentation“ und den Auxbar-Schalter ergänzt der Host. Die rechte Modul-Rail .wk-shell-rail--right (layout) rendert nur noch im Rückfallpfad, wenn der Host die Schale nicht übernimmt. Begründung: Historie und Berechtigungen betreffen eine Verbindung; eine Leiste über dem ganzen Modul kann nicht sagen, welche sie meint. Im Menü der Verbindung stellt sich die Frage nicht.
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 [S2]. Begründung: DokuWiki ist Multi-Request ohne persistente Server-Sitzung je Verbindung – ein ADS-artiger Verbindungs-Lebenszyklus hätte kein Substrat.
4. Tastenkürzel ohne Browser-Kollision [Live]. „Ausführen“ lösen F5 und Strg+Enter aus, „Syntax prüfen“ Strg+F5. Ein Kürzel klickt nur die sichtbare Schaltfläche (data-wk-shortcut, ausgewertet von shortcuts.js aus wkfluentui); wo „Ausführen“ fehlt, lädt F5 die Seite wie gewohnt neu. Vollständige Tabelle in Abschnitt 2.6. Begründung: Ein Kürzel darf keinen zweiten Absendeweg öffnen und keine Aktion erreichen, die der Benutzer nicht sieht.
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).

Referenzen auf den Azure-Data-Studio-Quelltext; Stufenmarke je Aktion. Farbspalte = Contract-v3-Semantik (w=weiß/neutral, b=blau/Sonder, r=rot/destruktiv).

Ein Verbindungs-Dropdown gibt es in der Titelleiste nicht: Der Baum zeigt alle konfigurierten Verbindungen als Wurzelknoten, gewählt wird per Klick. Den Auxbar-Schalter stellt der Host.

Jeder Knoten trägt ein Menü „Aktionen“; das Kontextmenü (Rechtsklick) löst nur dieselben Links und Schaltflächen erneut aus, einen zweiten Absendeweg gibt es nicht. Jeder Eintrag wird gegen seine eigene Fähigkeit geprüft.

Dies ist 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.

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

Eine Modulaktion: Neue Abfrage – und keine Dokumentation. Die legt adminshell::commandsFor() ohnehin aus plugin.info.txt an; ein eigener Beitrag erschiene doppelt. „Abfrage-Historie“ und „Berechtigungen“ stehen im Menü der Verbindung (Abschnitt 2.2).

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

• Titelleisten-Aufbau [Live]: Neue Verbindung, Aktualisieren, Alles aus-/einklappen, darunter der Objekt-Filter; 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: das Studio zeichnet keine eigene Schale. Es gibt seine Teile als Beiträge nach Contract v1 ab – Objektbaum in sidebar, Objekteigenschaften in auxbar, Ergebnisse in bottomPanel, die Modulaktion in commandPalette – und der Host baut das Raster darum.

Eine eigene Schale hätte zwei Folgen: action_plugin_wkfluentui_adminworkbench::compose() kehrt bei ownsItsShell() sofort zurück, und damit entstünden weder Aktivitätsleiste noch Modulreiter – aus dem Studio führte dann kein Weg zu einem anderen Modul. Und der Objektbaum hinge an einem vorlagenspezifischen 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: die Studio-Fläche liegt direkt in <main>, ohne den Dokumentrahmen, den die Vorlage sonst um eine Wiki-Seite zeichnet (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 nötig, weil SCAN c USING INDEX idx_comments_created mit SCAN beginnt, aber den Index liest – „Ganze Tabelle“ wäre dort falsch. 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. Ein geschlossener Zweig kostet damit keine Introspektionsabfragen (vier je Tabelle) und lädt kein Routinen-Manifest.

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. Beide Einführungsstufen sind abgeschlossen; Ablauf und Grenzfälle: Berechtigungen.

• Fähigkeiten: use (Routinen testen; öffnet allein den Bereich „Routinen“) · 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, innerhalb eines Scopes Benutzer vor Gruppe) – 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.
• Service-Aufrufe über sql.routines sind nicht an die Matrix gebunden: Der Service ist ein eigener, vertrauenswürdiger Aufrufer (API-Referenz → Service).

Beispiel (acl.auth.php-Notation, illustrativ – nicht das Dateiformat; Regeln werden im Matrix-Dialog gepflegt):

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

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.

Zielzustand:

1. Grid-Konsistenz: Verbindungen, Routinen und Tabellen-Übersicht sind dataGrid()-Raster mit Spaltensortierung und Menü „Aktionen“ je Zeile [Live]; die Table-Designer-Register nutzen noch die schlichte Tabelle [S2]. Mehrfachauswahl nur dort, wo eine sinnvolle Massenaktion existiert.
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“.

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.

Vorbild: das Workbench-Layout von WDX (WdxWorkbenchLayout: Titlebar · Command-Bar · Activity-Bar · Sidebar · Editor · Panel · Statusbar) – dort liegt jede Arbeitsfläche innerhalb der Workbench-Regionen, auch Formular- und Detail-Screens.

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; in der Host-Schale als Bereichs-Fusszeile .wkq-panestatus gezeichnet, 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: 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 über den Toast-Host wkToast() aus wkfluentui (admin-layout, Regel „Toast-Host“). Der Bereichs-Pivot (Verbindungen/Abfragen-Assistent/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. [S2]-Bausteine
• Styles-Contract (--wk-*) – Contract v3 (Farbsemantik/Tokens)
• SQLite Data Studio – Studio-Produktdoku (Wegweiser, Routinen/Verbindungen/API/How-to)