Ein Flurmonitor mit Thymeleaf: das Projekt im Überblick

Ein Flurmonitor mit Thymeleaf: das Projekt im Überblick

https://bildung.social/@oerinformatik/

https://oer-informatik.de/thymeleaf-flurmonitor-projekt

Thymeleaf, Spring Boot, serverseitiges Rendern, Template-Engine, Scrum, Sprint, Flurmonitor, Spring MVC, Testebenen, Selenium, Mitfahr-App

tl/dr; (ca. 18 min Lesezeit): 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 [AI-Assisted]. (Zuletzt geändert am 11.11.2026)

Dieser Artikel ist Teil einer Artikelreihe über den Flurmonitor mit Thymeleaf: Projektübersicht / Scrum-Projektstart / Thymeleaf einbinden / Templates / Ansichtsmodell / Integrationstest der Web-Schicht / Konfiguration und Formatierung / Aktualisierung / Hinweise mit Formularen / Robustheit und Betrieb / GUI-Test mit Selenium / Akzeptanztest / Change Request Keycloak

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

Im Foyer und auf den Fluren des DBH-Berufskollegs hängen große Bildschirme. Künftig sollen sie die offenen Fahrten der Mitfahr-App Mitfahrlabor anzeigen: Wer in der Pause vorbeigeht, sieht auf einen Blick, wer morgen früh ab Herford noch Plätze frei hat. Das Backend dafür steht, es liefert die Daten über eine REST-Schnittstelle als JSON. Was fehlt, ist eine Oberfläche.

In dieser Artikelreihe baust Du diese erste Oberfläche, den Flurmonitor. Seine Seiten entstehen nicht im Browser, sondern im Spring-Boot-Backend selbst, mit der Template-Engine Thymeleaf. Dabei arbeitest Du wie ein kleines Entwicklungsteam nach Scrum: in Sprints, mit Backlog, Review und Retrospektive. Der Fahrplan zeigt, welcher Artikel in welchen Sprint fällt:

Worum es geht: Fahrten im Vorbeigehen entdecken

Die Anforderung an den Flurmonitor steht schon im Backend. Im ersten Backend-Artikel (Anforderungen und API-Entwurf) wurde sie als User Story mit drei Abnahmekriterien festgehalten:

US-08 Offene Angebote anonym anzeigen: Als Flurmonitor möchte ich die offenen Angebote anzeigen, damit Auszubildende im Vorbeigehen Fahrten entdecken.

Der Flurmonitor hat besondere Nutzende: Niemand bedient ihn, niemand meldet sich an, und gelesen wird er im Vorbeigehen aus einigen Metern Entfernung. Hinter jedem Bildschirm steckt ein Mini-Player in einem eigenen Netz der Schule, auf dem keine personenbezogenen Daten liegen sollen. Aus diesen Bedingungen entstehen im Scrum-Projektstart weitere Einträge für das Backlog, etwa ein Monitor je Haltepunkt, eine gut lesbare Darstellung, Hinweise der Schulverwaltung („Bus fällt aus“) und eine Anzeige, die sich selbst aktualisiert.

Das Aussehen der Seite kennst Du schon: In den Grundlagenartikeln zu HTML, CSS und Bootstrap ist eine statische Abfahrtsanzeige entstanden, mit festen Beispieldaten im HTML. Genau diese Seite wird in dieser Reihe zum Template, das der Server mit echten Daten füllt.

Seite auf dem Server oder im Browser bauen?

Eine Web-Oberfläche kann ihr HTML an zwei Stellen zusammensetzen. Beim serverseitigen Rendern (server-side rendering, SSR) erzeugt der Server zu jeder Anfrage eine fertige HTML-Seite und schickt sie an den Browser, der sie nur noch anzeigt. Dafür nutzt der Server eine Template-Engine: ein Programm, das eine HTML-Vorlage (Template) mit Platzhaltern nimmt und die Platzhalter mit Daten aus einem Modell füllt. Thymeleaf ist eine der Template-Engines, für die Spring Boot eine fertige Einbindung (einen Starter) mitbringt; Alternativen sind etwa FreeMarker, Mustache oder Groovy Templates.

Beim clientseitigen Rendern lädt der Browser einmal eine JavaScript-Anwendung, eine Single-Page-App (SPA). Sie holt die Daten selbst per REST als JSON und baut daraus im Browser das HTML. So arbeitet die Web-App der nächsten Artikelreihe mit Vue 3.

Für den Flurmonitor spricht vieles für das serverseitige Rendern: Er wird nicht bedient, die Mini-Player sind leistungsschwach, und es gibt keine Anmeldung, die eine App verwalten müsste. Außerdem liegt die Oberfläche im selben Projekt wie die Fachlogik, sodass keine zweite Anwendung gebaut, ausgeliefert und betrieben werden muss. Die Grenzen zeigen sich, sobald Nutzende viel klicken, suchen und buchen sollen. Dafür entsteht in der nächsten Reihe die Web-App, und die Artikel zur Aktualisierung zeigen schon, wie eine serverseitige Seite einzelne Teile nachladen kann.

Thymeleaf hat dabei eine Besonderheit: Seine Templates sind Natural Templates. Die Platzhalter stehen als zusätzliche Attribute in gültigem HTML, und zwischen den Tags bleiben die Beispieldaten stehen. Öffnest Du das Template direkt im Browser, siehst Du die statische Abfahrtsanzeige; liefert der Server es aus, ersetzt Thymeleaf die Beispieldaten durch echte Werte:

<tr th:each="eintrag : ${eintraege}">
  <td th:text="${eintrag.ort}">Gütersloh</td>
  <td th:text="${eintrag.zeit}">07:00</td>
  <td th:text="${eintrag.plaetze}">2</td>
</tr>

th:each wiederholt die Tabellenzeile für jeden Eintrag der Liste, th:text ersetzt den Inhalt der Zelle. Die vollständige Ausdruckssprache folgt im Artikel zu den Templates.

Wo der Flurmonitor im Backend sitzt

Der Flurmonitor ist keine eigene Anwendung. Er kommt als zusätzliche Klasse in die Web-Schicht des bestehenden Backends und nutzt dieselbe Service-Schicht wie die REST-Schnittstelle. Damit gelten die Fachregeln aus dem Backend, zum Beispiel welche Angebote als offen gelten, für beide Wege gleichermaßen:

Der Unterschied liegt in einer einzigen Annotation und im Rückgabewert. Ein @RestController gibt Daten zurück, die Spring als JSON in die Antwort schreibt. Ein @Controller gibt dagegen den Namen eines Templates zurück; die Daten dafür legt er vorher im Model ab. Spring sucht das Template unter src/main/resources/templates/ und lässt es von Thymeleaf rendern. Dieses Zusammenspiel heißt Model-View-Controller (MVC): Der Controller nimmt die Anfrage an, das Model trägt die Daten, die View (hier das Template) stellt sie dar. Vereinfacht sieht das so aus; die Namen von Service und Eintrag sind Platzhalter, im Backend implementiert der REST-Controller zudem die aus dem OpenAPI-Vertrag erzeugte Schnittstelle:

@RestController
public class MonitorRestController {           // liefert Daten (JSON)

    private final MonitorService monitorService;

    public MonitorRestController(MonitorService monitorService) {
        this.monitorService = monitorService;
    }

    @GetMapping("/monitor/eintraege")
    public List<MonitorEintrag> eintraege() {
        return monitorService.offeneEintraege();  // wird zu JSON
    }
}

@Controller
public class FlurmonitorController {           // liefert eine Seite (HTML)

    private final MonitorService monitorService;

    public FlurmonitorController(MonitorService monitorService) {
        this.monitorService = monitorService;
    }

    @GetMapping("/flurmonitor")
    public String anzeigen(Model model) {
        model.addAttribute("eintraege", monitorService.offeneEintraege());
        return "flurmonitor";                    // Name des Templates
    }
}

Beide Controller bekommen den Service per Konstruktorinjektion, wie Du es aus dem Backend kennst. Weil der Flurmonitor keine Anmeldung kennt, muss die Sicherheitskonfiguration des Backends die Seiten unter /flurmonitor und die statischen Dateien (CSS, Bilder) ohne Anmeldung freigeben. Die Verwaltungsseiten für Hinweise dagegen bleiben geschützt; am Ende der Reihe meldet man sich dort über einen Identity Provider an.

Scrum: so arbeitet das Team

Die Backend-Reihe folgte dem V-Modell: erst alle Entwürfe, dann Implementierung und Tests von unten nach oben. Für den Flurmonitor wählt das Team ein agiles Vorgehen, Scrum. Statt alles vorab festzulegen, entsteht die Oberfläche in kurzen, festen Zeitabschnitten, den Sprints. Am Ende jedes Sprints steht ein lauffähiges Zwischenergebnis, das Inkrement, das sich der Auftraggeber ansehen kann. Seine Rückmeldung fließt in den nächsten Sprint ein. Das passt zu einer Oberfläche, bei der sich vieles erst zeigt, wenn man sie am echten Bildschirm im Flur sieht.

Scrum legt drei Verantwortlichkeiten, fünf Ereignisse und drei Artefakte fest. Im Projekt sind sie so besetzt:

Was „fertig“ heißt, legt das Team in der Definition of Done fest, etwa: Tests grün, Pipeline grün, Seite auf einem Bildschirm in Full HD geprüft. Wie Product Backlog, Abnahmekriterien, Schätzung mit Planning Poker und Release-Plan entstehen, zeigt der erste Artikel der Reihe. Jeder folgende Artikel beginnt mit dem Stand im Sprint und endet mit dem nächsten Schritt.

Der Fahrplan: zwölf Artikel in vier Sprints

Der Fahrplan im Bild oben geht von Sprints mit zwei Wochen aus. Die Längen der einzelnen Balken sind nur grobe Schätzungen; in Scrum plant das Team die Arbeit im Sprint Planning selbst. Die Reihe folgt diesem Plan:

Zu jedem Artikel gibt es einen eigenen Übungsartikel mit Aufgaben auf mehreren Kompetenzstufen. Für einen Artikel solltest Du mit Ausprobieren etwa 40 Minuten einplanen.

Testebenen: vom Ansichtsmodell bis zur Abnahme

Auch wenn das Vorgehen agil ist, werden die Testebenen aus dem V-Modell nicht überflüssig. Sie wandern nur in die Sprints: Jeder Sprint liefert getesteten Code, und die Definition of Done verlangt die passenden Tests. Wie Du Tests planst, beschreibt der Artikel zur Teststrategie.

Ab dem ersten Sprint laufen alle Tests in der CI-Pipeline des Backends mit. Der Change Request in Artikel 12 ändert die Anmeldung für das ganze Backend; danach müssen alle Ebenen noch einmal grün werden.

Voraussetzungen und Code zum Mitmachen

Die Reihe setzt das fertige Backend voraus. Du solltest die Backend-Reihe mit Spring Boot durchgearbeitet haben oder zumindest ihren letzten Code-Stand verstehen: Schichten, Konstruktorinjektion, Services, Tests mit JUnit und die CI-Pipeline. Für die Seiten selbst brauchst Du die Grundlagen von HTML, CSS und Bootstrap.

Den Code jedes Artikels findest Du als eigenen Zwischenstand im Ordner src des Backend-Repositorys. Die Stände der Flurmonitor-Reihe tragen ein a vor der Nummer (src/a02-…/mitfahrlabor, src/a03-…/mitfahrlabor) und bauen auf dem letzten Backend-Stand auf. Hängst Du fest, machst Du mit dem Stand des vorigen Artikels weiter.

Wie im Backend wählst Du Varianten über Tabs aus: das Build-Tool (Gradle als Standard oder Maven) und die Shell (PowerShell als Standard oder Bash). Im letzten Artikel kommt eine Auswahl für den Identity Provider Keycloak dazu: als ZIP-Download, der nur ein Java-JDK braucht, oder mit Docker.

Der Übungsstrang: Mitfahrgesuche

In den Artikeln geht es immer um die Fahrtangebote. Die Übungen führen den Strang fort, den Du aus den Backend-Übungen kennst: die Mitfahrgesuche. Wer keine passende Fahrt findet, kann ein Gesuch aufgeben, und auch diese Gesuche sollen anonym auf dem Monitor erscheinen. In den Übungsaufgaben baust Du dafür Schritt für Schritt eine eigene Gesuche-Seite mit derselben Technik wie im jeweiligen Artikel: Controller und Template, Ansichtsmodell mit Tests, Formular zum Aufgeben, GUI-Test und Akzeptanztest.

Nächster Schritt: Sprint 0

Bevor die erste Zeile Thymeleaf entsteht, braucht das Team eine gemeinsame Vorstellung vom Produkt. Im Scrum-Projektstart formulierst Du die Produktvision, schreibst das Product Backlog für den Flurmonitor, legst die Definition of Done fest und schätzt die User Stories mit Planning Poker. Daraus entsteht der Release-Plan für die drei Sprints.

Leitfragen

1. Was unterscheidet serverseitiges Rendern mit einer Template-Engine von einer Single-Page-App? Antwort

Beim serverseitigen Rendern füllt der Server ein HTML-Template mit Daten und schickt die fertige Seite; eine Single-Page-App lädt einmal JavaScript, holt die Daten per REST als JSON und baut das HTML im Browser. siehe Abschnitt „Seite auf dem Server oder im Browser bauen?“

2. Warum eignet sich serverseitiges Rendern für den Flurmonitor? Antwort

Der Monitor wird nicht bedient, braucht keine Anmeldung und läuft auf leistungsschwachen Mini-Playern; außerdem liegt die Oberfläche im selben Projekt wie die Fachlogik, sodass keine zweite Anwendung betrieben werden muss. siehe Abschnitt „Seite auf dem Server oder im Browser bauen?“

3. Worin unterscheiden sich @Controller und @RestController, und was haben sie im Flurmonitor gemeinsam? Antwort

Der @RestController gibt Daten zurück, die als JSON in die Antwort geschrieben werden; der @Controller legt Daten im Model ab und gibt den Namen eines Templates zurück, das Thymeleaf zu HTML rendert. Beide nutzen dieselbe Service-Schicht und damit dieselben Fachregeln. siehe Abschnitt „Wo der Flurmonitor im Backend sitzt“

4. Welche Abnahmekriterien gehören zur User Story US-08? Antwort

Einträge enthalten Ort, Treffpunkt, Richtung, Datum, Zeit und freie Plätze, aber keine Namen oder Pseudonyme (AK-08.1); vergangene, volle und abgesagte Angebote fehlen (AK-08.2); bei einer Höchstzahl kommen höchstens so viele Einträge, die frühesten zuerst (AK-08.3). siehe Abschnitt „Worum es geht: Fahrten im Vorbeigehen entdecken“

5. Welche Verantwortlichkeiten, Ereignisse und Artefakte kennt Scrum? Antwort

Product Owner, Developers und Scrum Master; Sprint, Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospective; Product Backlog, Sprint Backlog und Inkrement. siehe Abschnitt „Scrum: so arbeitet das Team“

6. Mit welchen Werkzeugen testet die Reihe auf welcher Testebene? Antwort

Komponententest mit JUnit und fester Uhr, Integrationstest der Web-Schicht mit @WebMvcTest, MockMvc und HtmlUnit, Systemtest über die Oberfläche mit Selenium und Abnahmetest mit Gherkin, Cucumber und Selenium. siehe Abschnitt „Testebenen: vom Ansichtsmodell bis zur Abnahme“

7. Wann stößt serverseitiges Rendern an seine Grenzen? Antwort

Wenn Nutzende viel bedienen, suchen und buchen, lädt jede Aktion eine neue Seite; eine Single-Page-App reagiert dann flüssiger und kann auch offline arbeiten, braucht aber ein eigenes Projekt und mehr Leistung im Endgerät. siehe Abschnitt „Seite auf dem Server oder im Browser bauen?“

8. Warum laufen nach dem Change Request in Artikel 12 alle Tests erneut? Antwort

Der Change Request ändert die Anmeldung für das ganze Backend, also auch für REST-Schnittstelle und Verwaltungsseiten; nur ein Regressionstest über alle Ebenen zeigt, dass nichts Bestehendes kaputtgegangen ist. siehe Abschnitt „Testebenen: vom Ansichtsmodell bis zur Abnahme“

Links und weitere Informationen

• für den Einstieg: Szenario Mitfahrlabor mit Personas und Flurmonitoren

• für den Einstieg: Ein REST-Backend mit Spring Boot: das Projekt Mitfahrlabor

• als Hintergrund: Scrum und Vorgehensmodelle

• als Hintergrund: Das V-Modell und Teststrategie

• als Nachschlagewerk: Dokumentation von Thymeleaf

• als Nachschlagewerk: Der Scrum Guide, auch in deutscher Übersetzung

• als Nachschlagewerk: Spring-Boot-Dokumentation zu Template-Engines

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Ein Flurmonitor mit Thymeleaf: das Projekt im Überblick” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/thymeleaf-flurmonitor-projekt veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/java-springboot/Backend. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 11.11.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]