az/morz-infoboard
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
No description
45 commits 1 branch 0 tags 4.1 MiB
Find a file
Jesko Anschütz cfab277dc4 Fuege HTML-Detailseite und HTML-Fehlerseite fuer den Status-UI-Pfad hinzu 
Drei eng zusammenhaengende Aenderungen in einem Commit, da sie dieselbe
Template-Infrastruktur teilen und gemeinsam die HTML-Diagnoseansicht
abrunden:

1. CSS-Extraktion (Verbesserung, kein Verhalten geaendert)
   Das bisherige Inline-CSS wurde in die Konstante statusPageCSS
   ausgelagert. statusPageCSSBlock injiziert es per String-Konkatenation
   in alle Templates, sodass kein Template-Inheritance-Mechanismus
   benoetigt wird und jede Seite eigenstaendig ausfuehrbar bleibt.

2. GET /status/{screenId} -- neue HTML-Detailseite
   Zeigt den letzten bekannten Datensatz eines einzelnen Screens:
   Derived State, Player-Status, Connectivity und Frische als
   Summary-Cards; Timing- und Endpoints-Details in aufgeraeuemten
   Key-Value-Tabellen. Verlinkung zurueck auf /status und auf den
   bestehenden JSON-Endpunkt. Bei unbekanntem Screen: 404 mit HTML-
   Fehlerseite und Rueck-Link.
   Route: GET /status/{screenId}

3. HTML-Fehlerseite fuer /status bei ungueltigen Query-Parametern
   Bisher lieferte handleStatusPage einen rohen JSON-Fehler, wenn
   z.B. ?stale=banana uebergeben wurde -- inkongruent fuer einen
   HTML-Endpunkt. writeStatusPageQueryError rendert jetzt dasselbe
   statusPageErrorTemplate wie der Not-Found-Fall der Detailseite
   und gibt text/html mit 400 zurueck.

Neue Tests (router_test.go):
- ScreenDetailPageRoute: prueft Inhalt, Links, Content-Type
- ScreenDetailPageNotFound: prueft 404 + HTML + Rueck-Link
- StatusPageRejectsInvalidQueryParams: prueft jetzt auch text/html
  fuer alle Fehlerfaelle

Docs (PLAYER-STATUS-HTTP.md):
- Query-Parameter-Validierung mit erlaubten Werten und Fehlercodes
- Neue /status/{screenId}-Seite und HTML-Fehlerseiten dokumentiert

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-03-22 20:03:24 +01:00
ansible Baue Layout-Resolver und lokale Entwicklungsgerueste aus 2026-03-22 16:03:21 +01:00
compose Baue Layout-Resolver und lokale Entwicklungsgerueste aus 2026-03-22 16:03:21 +01:00
docs Fuege HTML-Detailseite und HTML-Fehlerseite fuer den Status-UI-Pfad hinzu 2026-03-22 20:03:24 +01:00
player Schaerfe Semantik des Statuspfads nach 2026-03-22 18:41:32 +01:00
server Fuege HTML-Detailseite und HTML-Fehlerseite fuer den Status-UI-Pfad hinzu 2026-03-22 20:03:24 +01:00
.gitignore Baue Layout-Resolver und lokale Entwicklungsgerueste aus 2026-03-22 16:03:21 +01:00
.golangci.yml Richte revive auf den Repo-Stil aus 2026-03-22 17:56:47 +01:00
API-MQTT-VERTRAG.md Dokumentiere ersten HTTP-Statuspfad fuer den Agenten 2026-03-22 17:43:08 +01:00
DATENMODELL.md Erweitere Planung um Templates und Provisionierung 2026-03-22 13:06:31 +01:00
DEVELOPMENT.md Mache Statusseite als Diagnoseansicht nutzbarer 2026-03-22 19:39:17 +01:00
LINTER-FINDINGS.md Dokumentiere aktuellen Linter-Stand 2026-03-22 17:53:32 +01:00
Makefile Integriere golangci-lint in den Entwicklungsablauf 2026-03-22 17:53:24 +01:00
PLAN.md Erweitere Planung um Templates und Provisionierung 2026-03-22 13:06:31 +01:00
README.md Dokumentiere ersten HTTP-Statuspfad fuer den Agenten 2026-03-22 17:43:08 +01:00
TECH-STACK.md Erweitere Planung um Templates und Provisionierung 2026-03-22 13:06:31 +01:00
TODO.md Triff verbindliche Architekturentscheidungen 2026-03-22 13:35:41 +01:00

README.md

Info-Board Neu

Dieses Verzeichnis enthaelt die Planung und spaetere Umsetzung der neuen Info-Board-Plattform.

Die Trennung von /srv/docker/infoboard-netboot ist sinnvoll, damit:

  • die bestehende produktive Netboot-Struktur unangetastet bleibt
  • Planung, Prototypen und neue Deployments sauber getrennt sind
  • Server-, Player- und Ansible-Artefakte nicht mit Altbestand vermischt werden

Aktueller Stand

  • Architekturplan: PLAN.md
  • Umsetzungs-Todo: TODO.md
  • Datenmodell: DATENMODELL.md
  • Schema-Entwurf: docs/SCHEMA.md
  • API- und MQTT-Vertrag: API-MQTT-VERTRAG.md
  • Technologieentscheidungen: TECH-STACK.md
  • Entwicklungsleitfaden: DEVELOPMENT.md
  • Erste Dev-Testliste: docs/TEST-CHECKLIST-DEV.md
  • Template-/Kampagnenkonzept: docs/TEMPLATE-KONZEPT.md
  • layout_json fuer message_wall: docs/LAYOUT-JSON.md
  • Player-Agent-Lifecycle und Health-Modell: docs/PLAYER-AGENT-LIFECYCLE.md
  • Erster HTTP-Statuspfad fuer den Player-Agent: docs/PLAYER-STATUS-HTTP.md
  • Provisionierungskonzept: docs/PROVISIONIERUNGSKONZEPT.md
  • Player-Konzept: docs/PLAYER-KONZEPT.md
  • Server-Konzept: docs/SERVER-KONZEPT.md
  • Offene Architekturfragen: docs/OFFENE-ARCHITEKTURFRAGEN.md

Projektstruktur

  • docs/ fuer weitere Architektur- und Betriebsdokumente
  • server/ fuer Backend, Frontends und Compose-Dateien
  • player/ fuer Agent, UI und lokale Startlogik
  • ansible/ fuer Rollen, Inventories und Deployments
  • compose/ fuer Container-Definitionen und Stack-Bausteine
  • scripts/ fuer Hilfsskripte

Aktueller Implementierungsstand

  • server/backend/ enthaelt ein lauffaehiges Go-Grundgeruest mit erster Tool-API fuer message_wall und einem ersten player/status-Endpunkt
  • player/agent/ enthaelt ein Go-Grundgeruest mit dateibasierter/env-basierter Konfiguration, strukturierten Logs, internem Health-Modell und erstem HTTP-Status-Reporter
  • compose/ enthaelt ein lokales Grundgeruest fuer PostgreSQL und Mosquitto
  • ansible/ enthaelt erste Platzhalter fuer Inventory und Playbook-Struktur

Naechste sinnvolle Inhalte in der Struktur

  • docs/ fuer weitere technische Detaildokumente
  • server/ fuer API, Admin-UI und Tenant-UI
  • player/ fuer player-agent, player-ui und lokale Startlogik
  • ansible/ fuer Rollen und Inventories
  • compose/ fuer den zentralen Server-Stack