Ansichten

Was ist das

Eine Ansicht ist eine JSON-Spezifikation aus Widgets. Jedes Widget bindet eine gespeicherte Abfrage über deren Namen. SQL steht nie in der Ansicht selbst, nur der Name der Abfrage, die die Zeilen liefert.

Eine Ansicht läuft am Terminal genauso wie im Büro. Ein Schichtleiter sieht dieselbe Definition auf einem großen Bildschirm wie ein Bediener auf dem Terminal neben der Maschine, nur mit anderer Größe der Bedien-Widgets. Weisen Sie eine Ansicht einer Gruppe zu, wird daraus eine Abteilung mit eigener Kachel auf der Seite „Abteilungen“. Die Zuweisung und das Anheften einer Ansicht an die Seitenleiste erklärt Navigation & Erscheinungsbild.

Wann einsetzen

Sie greifen zu einer Ansicht, sobald ein Bildschirm Zahlen oder Buchungen zeigen soll, statt beides in eigenem Code zu bauen.

Abteilungsübersicht. Eine Übersicht aus Kennzahlen und Maschinenzuständen für eine ganze Abteilung, meist ohne Parameter.
Maschinendetail. Eine Ansicht mit Kontextparameter, die den Zustand, die Warteschlange und die Buchungsschaltflächen der aufgerufenen Maschine zeigt.
Cockpit. Eine Ansicht aus reinen Lese-Widgets für Planer und Werksleitung, ohne Aktions-Widgets, weil hier niemand bucht.
Terminal-Bildschirm. Eine Ansicht mit großen Bedien-Widgets neben der Maschine, für den Bediener, der scannt und abschließt.

Wer nur Daten zeigen will, baut eine Ansicht aus Lese-Widgets. Wer buchen lassen will, hängt zusätzlich ein Aktions-Widget oder ein Scan-Feld hinein.

Anatomie der Definition

Der Widget-Katalog ist größer als die folgende Liste; das sind die wichtigsten Typen, die eine Abfrage binden:

stat: ein einzelner Kennzahlwert, aus der ersten Zahl der ersten Zeile oder aus der Anzahl der Zeilen.
table: Spalten und Zeilen, unverändert.
matrix: eine Status-Matrix aus Zeilen mit row, col, ok, stuck, err; Zellen zeigen die drei Zähler als grüne, gelbe und rote Pille.
lot-queue: Zeilen mit losartigen Feldern (id/lot_id, order_number, qty, status); jede Zeile verlinkt zur Los-Genealogie.
machine-grid: Zeilen mit id, name, state.
timeseries: Zeilen mit einer Zeitstempel-Spalte und einer Zahlen-Spalte.
bar: Zeilen mit einer Text-Spalte als Beschriftung und einer Zahlen-Spalte.
scrap-pareto: Zeilen mit einer Grund-Spalte und einer Zahlen-Spalte.
detail: eine einzelne Zeile als aufklappbares Schlüssel-Wert-Panel, gebunden an eine By-Id-Abfrage.
schedule-gantt: Zeitbalken aus Zeilen mit label, start, end; eine Spur-Spalte gruppiert Balken auf eine Zeile, eine Status-Spalte färbt den Balken.
genealogy-graph: der Abstammungs- und Nachkommen-Graph eines Loses.
form: schreibt eine Zeile einer eigenen Entität aus der Ansicht heraus, im Modus create oder update.

Zwei weitere Typen binden bewusst keine Abfrage. telemetry zeigt laufende Maschinendaten live über SSE. date-range bindet ebenfalls keine Abfrage, sondern steuert den Zeitraum von Kennzahlen-Widgets auf derselben Ansicht. Einen Sonderfall bildet custom-code: Es bindet eine selbst geschriebene Oberfläche statt eines der Standard-Widgets ein, für Fälle, die der übrige Katalog nicht abdeckt.

Dazu kommen drei Widgets für Navigation und Buchung. nav-list verwandelt die Zeilen einer Abfrage in Links zu einer parametrisierten Ansicht und führt damit von einer Übersicht zum Detail. action löst eine Aktion über deren Namen aus. Eine bind-Zuordnung liefert die Eingaben; submit legt die Beschriftung der Schaltfläche fest. scan-input übernimmt einen Scan entweder in einen Parameter (mode: "param") oder direkt als Eingabe einer Aktion (mode: "action").

Jedes Widget trägt optional ein chrome-Objekt mit title, icon, accent und size. icon ist einer aus einer festen, serverseitig validierten Liste wie scan-barcode, factory, gauge oder wrench; verwenden Sie für chrome.icon die Auswahl im Baukasten. accent ist eine aus brand, blue, green, amber, violet, red, slate. size ist default oder large.

Eine Ansicht, die zwischen mehreren Maschinen wechseln soll, deklariert dafür einen Kontextparameter im übergeordneten params-Array. Widgets referenzieren ihn mit {"$param":"machine"}. Den Wert füllt die Anwendung aus der URL. So entsteht aus einer einzigen Detailansicht die Seite für jede Maschine im Werk, ohne eine Kopie je Maschine zu pflegen.

Die Bindung entscheidet, welchen Daten- oder Buchungspfad ein Widget verwendet. Lese-Widgets binden gespeicherte Abfragen, Aktions-Widgets binden Aktionen, und das Widget für Maschinendaten bindet eine Maschine für den Live-Strom.

flowchart LR
    Url["URL-Parameter"] --> Params["Ansichtsparameter"]

    subgraph View["Ansicht"]
        Params --> ReadWidget["Lese-Widget"]
        Params --> ActionWidget["Aktions-Widget"]
        Params --> TelemetryWidget["Maschinendaten-Widget"]
        DateWidget["Zeitraum-Widget"] --> ReadWidget
    end

    ReadWidget --> Query["Gespeicherte Abfrage"]
    Query --> Data["Abgeleitete Daten"]
    ActionWidget --> Action["Aktion"]
    Action --> Booking["Buchung"]
    TelemetryWidget -->|"Maschine"| Live["Live-Daten über SSE"]

Zur Orientierung folgt eine kompakte Startübersicht aus einer Beispielkonfiguration:

{
  "view": "home-dashboard",
  "title": "Dashboard",
  "layout": { "type": "grid", "cols": 12 },
  "widgets": [
    { "type": "bar", "bind": { "query": "machines_by_state", "params": {} }, "pos": [0, 0, 6, 4] },
    { "type": "bar", "bind": { "query": "lots_by_status", "params": {} }, "pos": [6, 0, 6, 4] },
    { "type": "stat", "bind": { "query": "lots_in_process", "params": {} }, "pos": [0, 4, 4, 2] },
    { "type": "table", "bind": { "query": "machines_overview", "params": {} }, "pos": [0, 6, 12, 5] }
  ]
}

Vier Widgets ohne einen einzigen Parameter: zwei Balken für Maschinenzustände und Los-Status, ein Kennzahlwert für laufende Lose, eine Tabelle mit allen Maschinen. pos legt Spalte, Zeile, Breite und Höhe im 12-spaltigen Raster fest.

Zum Erstellen gibt es den Baukasten unter „Ansichten“. Sie ordnen Elemente per Drag-and-drop an. Für jedes Widget gibt es ein Konfigurationsmenü mit Abfrageauswahl und Live-Vorschau. Der Assistent (✦) schlägt darüber hinaus vollständige Ansichten einschließlich Widget-Auswahl und Bindungen vor.

Beispiele

Die folgenden drei gebündelten Abfragen verwenden nur generische Tabellen und Parameter. Der Generator übernimmt ihre aktuelle Definition direkt aus dem Seed-Katalog. Eine umbenannte oder entfernte Abfrage lässt docs-check fehlschlagen.

-- machines_by_capability, params: capability
SELECT id, name, state FROM machines_current WHERE capabilities @> to_jsonb($1::text) ORDER BY name

Mit dem Assistenten

Zeig mir alle Maschinen mit einer bestimmten Fähigkeit als Kachel-Raster.

Ein Parameter capability filtert die Maschinen vorab in SQL. Die Abfrage liefert id, name und state je passender Maschine, genau die Zeilenform, die machine-grid und table erwarten. Ein machine-grid-Widget zeigt jede Zeile als Kachel mit ihrem Zustand.

-- machine_detail, params: machine_id
SELECT id, name, state, state_reason, capabilities, tooling FROM machines_current WHERE id = $1

Mit dem Assistenten

Ich brauche eine Detail-Ansicht mit einem Kontext-Parameter für die Maschine.

Das detail-Widget bindet machine_id an {"$param":"machine"}. Die Ansicht deklariert dafür machine in ihrem Top-Level-params-Array. So zeigt dieselbe Definition das Detail jeder Maschine, je nachdem, welchen Wert die URL mitbringt.

-- lots_queued_at_machine, params: machine_id
SELECT l.id, l.order_number, l.current_step,
       o.routing -> (l.current_step - 1) ->> 'name' AS step,
       l.qty_good AS qty
FROM lots_current l JOIN orders_current o ON o.id = l.order_id JOIN machines_current m ON m.id = $1 WHERE l.status = 'queued'
  AND m.capabilities @> to_jsonb(o.routing -> (l.current_step - 1) ->> 'capability')
ORDER BY l.order_number, l.id

Mit dem Assistenten

Baue mir eine Warteschlange der nächsten Kisten an einer Maschine.

Die Abfrage ist je Maschine parametrisiert und liefert die wartenden Lose in ihrer Reihenfolge. Sie ist die Quelle für das lot-queue-Widget am Terminal, damit der Bediener sieht, was als Nächstes kommt.

Fallstricke

Die Abfrage muss zuerst existieren. Ein Widget kann nur eine Abfrage binden, die bereits als gespeicherte Abfrage angelegt ist. Legen Sie zuerst die Abfrage an, dann das Widget, nicht umgekehrt.
Terminal-Ansichten brauchen size: "large". Ohne dieses Attribut im chrome-Objekt bleiben Bedien-Widgets auf einem Terminalbildschirm zu klein zum Antippen, insbesondere bei Handschuhen.
Von der Übersicht zum Detail führt nav-list. Ein Freitext-Link trägt keinen Kontextparameter mit. Nur nav-list reicht den Wert einer Zeile korrekt als $param an die Zielansicht weiter.
Ein $param ohne Eintrag im params-Array lässt sich nicht speichern. Die Ansicht muss jeden referenzierten Parameter selbst deklarieren. Fehlt der Eintrag, lehnt die Validierung die Bindung mit unknown param ab, und das Veröffentlichen scheitert mit Status 422, bis Sie den Parameter im params-Array nachtragen.

Wie eine gespeicherte Abfrage selbst aufgebaut ist, zeigt das Kapitel Gespeicherte Abfragen. Wie ein Aktions-Widget die dahinterliegende Aktion aufruft, beschreibt das Kapitel Aktionen. Wie das Cockpit aus Ansichten und Abfragen Kennzahlen macht, erklärt das Kapitel Kennzahlen & Cockpit. Das Anheften, die eingebauten Navigationseinträge, Abteilungen und die Grenzen des Icon-Katalogs behandelt Navigation & Erscheinungsbild.