I am trying Quarkus Qute (I wrote a custom implementation of ViewResolver) and the basics (model attribute display, include/insert) work well and is pleasant to use. But automatic form data binding is missing. Any plan to provide a ViewResolver for this template engine ? Even if is a part of the Quarkus ecosystem qute-core can be used without Quarkus and without too many dependencies (jboss-logger and Mutiny).

Already supported alternatives have their drawbacks:

Thymeleaf: * painful strings concatenation: <div th:text="|Hello: ${name}|"> or <div> hello <span th:text="${name}" th:remove="tag"/></div> * external dependency (nz.net.ultraq.thymeleaf:thymeleaf-layout-dialect) for layout master page.

Freemarker: * freemarker syntax (opening with <# and closing with </#) breaks HTML validation, * weird form data binding due to Freemarker syntax (<@spring.formInput path="command.birthDate" attributes='class="form-control"' fieldType="date"/>)

With Qute the template remains a valid HTML file, which avoids IDE errors.

Server side rendering is gaining popularity (which completely makes sens for UI that are just forms and lists) and framework like unpoly improve user experience. But even if template files are not HTML files, it is better if they pass IDE HTML validation and if frontend experts can write most of their content.

This proposal concerns spring-webmvc for the ViewResolver implementation and Spring Boot for the autoconfiguration and starter.

Comment From: bclozel

Spring Framework doesn't really accept new ViewResolver implementation, as the existing ones are mostly being used as reference implementations. The popular Thymeleaf project is shipping its own integration with Spring and we think this is a better approach as it co-evolves with the templating engine.

Given that the ViewResolver implementation is usually lightweight, I think that a project shipping both the ViewResolver and the auto-configuration would be a good tradeoff. Many community starters are listed on the dedicated page and are quite popular. We can always consider merging it in Spring Boot directly if it gains popularity.

Thanks!