Flurmonitor

Thymeleaf ins Backend einbinden: Controller, Model und das erste Template für den Flurmonitor

Sprint 1 beginnt: Die Developers zerlegen die erste Story des Flurmonitors in Aufgaben und binden Thymeleaf ins Spring-Boot-Backend ein. Ein @Controller nimmt die Anfrage an, legt Daten ins Model und gibt den Namen eines Templates zurück; Thymeleaf findet das Template unter classpath:/templates/ und rendert daraus HTML. Die statische Abfahrtsanzeige wird zum ersten Template, Stylesheet und Logo werden statische Ressourcen, Spring Security gibt die Seite ohne Anmeldung frei, und ein Smoke-Test prüft, dass das alles zusammen funktioniert.

Sprint 0 für den Flurmonitor: Vision, Product Backlog, Definition of Done und Planning Poker

Bevor der Flurmonitor die erste Zeile Thymeleaf bekommt, startet das Team das Projekt nach Scrum: Es besetzt die Verantwortlichkeiten, formuliert eine Produktvision und ein Produktziel, schreibt das Product Backlog mit User Stories und Abnahmekriterien in der Form Angenommen – Wenn – Dann, vereinbart die Definition of Done, schätzt mit Planning Poker und leitet daraus Release-Plan, Sprint-Ziel und Sprint Backlog für Sprint 1 ab. Dabei zeigt sich, warum die anonyme Anzeige eine Anforderung ist und kein Extra.

Ein Flurmonitor mit Thymeleaf: das Projekt im Überblick

In zwölf Artikeln bekommt das Mitfahrlabor-Backend eine erste Oberfläche: einen Flurmonitor, dessen HTML-Seiten der Server selbst mit der Template-Engine Thymeleaf erzeugt. Das Team arbeitet dabei nach Scrum in drei Sprints und prüft den Monitor auf allen Testebenen bis zur Abnahme. Hier findest Du den Fahrplan, die Voraussetzungen und die Einordnung ins Backend.

Fehler mit Format: restliche Endpunkte, Mapper und Problem Details nach RFC 9457

Seit Artikel 08 greifen die Fachregeln, aber jeder Verstoß endet als 500 Internal Server Error. Jetzt bekommt jede fachliche Ausnahme den Statuscode aus dem Vertrag: 404, 409 oder 422, beschrieben als Problem Details nach RFC 9457. Eine zentrale Klasse mit @RestControllerAdvice übernimmt das für alle Controller, auch für Vertragsverstöße (400). Dazu kommen die restlichen Endpunkte (Angebot ändern und absagen, Buchungen eines Angebots, Flurmonitor) und eigene Mapper-Klassen für die Umwandlung zwischen Entities und Vertragsmodellen.