java-templating
Java Templating
Preserve The Rendering Stack
Use the established engine, layouts, fragments and localization infrastructure. Do not replace Thymeleaf, FreeMarker, Mustache, or another engine merely to apply this skill. Verify actual escaping and rendering APIs for the installed version instead of copying helpers from another stack.
Keep rendering and route generation in presentation/web collaborators, with engine construction/configuration at the project's wiring boundary. Do not introduce engine types, requests, renderers, or route builders into domain models or repositories. Apply architecture skills only when explicitly activated by project instructions.
Typed Page Models
Prefer a page-specific immutable <Concept>PageViewModel that contains the complete application-provided page data. Structure nested models around semantic concepts such as metadata, header, content, and navigation; type collection elements. Do not replace every HTML element with a ViewModel or flatten structured domain data into loose maps merely because the framework accepts a model map.
When the project uses a page ViewService, it obtains/maps the necessary data and returns the complete page model. The controller adapts request values, calls that service, and renders with the established HTTP status/headers. Keep repository coordination, component composition and domain-to-presentation mapping outside the controller and template.
Keep presentation models free of requests, repositories, entities, vendor objects, HTML markup, and escaping behavior. Records can express data when supported; defensively copy mutable collections when required by the intended immutability contract. Preserve framework-required model entries and explicit project conventions rather than forcing one model object onto existing form binding or security helpers.
Read presentation examples when introducing a page model or localized email composition. Use java-readable-code for justified component factories and inspectable intermediate results.