Controllers and Views

A Spring MVC controller looks so much like an ordinary Java class that it's easy to forget how much work the framework does around it. A method declares @PathVariable Long id, @RequestParam int page, Model model and receives three ready-to-use values, extracted from three different places in the request, converted to the right type, and validated. None of these conversions appear in your code.

This economy comes at a price: when something goes wrong, the cause is often invisible because it lies in a convention you didn't know about. A path variable that arrives empty because its name doesn't match. A missing parameter that triggers a 400 when you wanted it to be optional. A redirect after a form submission that loses the confirmation message. An object added to the model but not found in the template.

All of these situations have the same origin: the contract between your method and the framework relies on names and types, not on explicit code. Understanding this contract means understanding where to look when it isn't honored.

This lesson details that contract in both directions — what a method can receive, what it can return — then moves on to the Thymeleaf view: iteration, reusable fragments, and the flash attribute mechanism that settles once and for all the problem of the confirmation message after a redirect.