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>
|
||
|---|---|---|
| .. | ||
| cmd/api | ||
| internal | ||
| Dockerfile | ||
| go.mod | ||
| README.md | ||
Backend
Dieses Verzeichnis enthaelt das erste Geruest fuer das zentrale Backend.
Ziel fuer die erste Ausbaustufe:
- HTTP-API in Go
- Health-Endpunkt
- saubere Projektstruktur fuer spaetere API-, Worker- und Datenbankmodule
- erste serverseitige Aufloesungslogik fuer
message_wall
Geplante Unterstruktur:
cmd/api/fuer den API-Startpunktinternal/app/fuer App-Initialisierunginternal/campaigns/fuer Kampagnen- und Template-Logikinternal/httpapi/fuer HTTP-Routing und Handlerinternal/config/fuer Konfiguration
Aktuell vorhanden:
GET /healthzGET /api/v1GET /api/v1/metaPOST /api/v1/tools/message-wall/resolveals erste serverseitige Layout-Aufloesung fuermessage_wall- einheitliches API-Fehlerformat im HTTP-Layer