Thymeleaf 3.0.10 JUST PUBLISHED

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Thymeleaf 3.0.10 JUST PUBLISHED

danielfernandez
Administrator

Thymeleaf 3.0.10 (3.0.10.RELEASE) has just been published.

This is a maintenance release with some bugfixing and feature changes. It should work as a drop-in replacement for 3.0.x versions. Have a look at our Download Page to learn how to obtain it.

JDK 11

Thymeleaf 3.0.10 has been tested with success on JDK 11.
Actually, this new version has been built on JDK 11, so as a consequence the new Java 11 JavaDoc format (frameless with search) has been adopted.

Note this does not affect the Java baseline (minimum required version), which continues to be Java 6 for the core and integration packages for Spring 3 and Spring 4, and Java 8 for the integration package for Spring 5.


THYMELEAF 3.0.10 CHANGE LOG

Changes to the Thymeleaf CORE:

  • Fixed StackOverflowError when inserting content before first element of model in a model processor.
  • Improved restricted expression evaluation mode to forbid output of textual data from context variables inside JavaScript event handlers in HTML templates.
  • Improved HTML event handler attributes (th:on*) in order to allow processing of their values as fragments of inlined JavaScript (using JAVASCRIPT template mode).
  • Improved use of template name abbreviation in logs and exceptions.
  • Added "Automatic-Module-Name" to MANIFEST.MF for Java 9+ JPMS.
  • Updated AttoParser dependency to 2.0.5.RELEASE
  • Updated Unbescape dependency to 1.1.6.RELEASE

Changes to the Thymeleaf SPRING integration packages:

  • Fixed th:field executing before th:remove and therefore potentially executing the ConversionService and the RequestDataValueProcessor for values that are not meant to be displayed in the HTML result, which could lead to unnecessary exceptions.
  • Fixed bean validation path not correctly binding expressions with brackets ([...]) when BindStatus was being obtained with optional = true.
  • Added a "renderHiddenMarkersBeforeCheckboxes" flag to SpringStandardDialect (also configurable from SpringTemplateEngine) in order to instruct th:field to render the <input type="hidden" ...> associated with checkbox fields before the checkbox itself and not after, in order to improve compatibility with several CSS-based frameworks.
  • Added a "producePartialOutputWhileProcessing" flag (default: true) to ThymeleafView and ThymeleafViewResolver in order to be able to specify whether Thymeleaf should start producing output as soon as possible during template processing (as is default) or on the contrary it should only start sending results to the web server's output buffers when processing of the template has completely finished and output is rendered in memory.
  • Added "Automatic-Module-Name" to MANIFEST.MF for Java 9+ JPMS.
Specific for thymeleaf-spring5:
  • [thymeleaf-spring5] Added support for non-blocking resolution (before View rendering) of specific reactive variables specified by dialects as execution attributes with "ThymeleafReactiveModelAdditions:" prefixed to their name.
  • [thymeleaf-spring5] Avoided blocking in the (reactive) resolution of the WebSession returned by the SeverWebExchange in WebFlux apps.

If you are interested, you can have a look at the list of issues on GitHub, which usually contain more detailed explanations:

And of course we invite you to visit the project website at http://www.thymeleaf.org


SPECIAL NOTES FOR THE Spring 5 WebFlux INTEGRATION

How does Thymeleaf operate in a reactive-friendly way for Spring 5 WebFlux?

Like previous versions, this new version of the Spring 5 integration module includes updated support for the new Spring 5 WebFlux reactive web framework. When used with WebFlux, Thymeleaf can operate in one of three reactive-friendly modes:

  • Full, producing all output in memory and sending it as a single output buffer.
  • Chunked, producing output in buffers (chunks) of a configurable maximum size and sending them to the client as they are produced.
  • Data-Driven, making Thymeleaf work as an integrated part of a reactive stream of data, rendering HTML for the produced data in a way fully sensible to reactive back-pressure, sending HTML chunks of output to the client as data is produced (and optionally shaping this HTML chunks into SSE events).

Read more about these reactive-friendly operation modes at the thymeleaf-spring5 JavaDocs.

Also, note that there are three sandbox applications prepared to serve as examples of the general thymeleaf-spring5 integration with Spring 5 WebFlux:

  • thymeleafsandbox-stsm-reactive, equivalent to the STSM sample application but using Spring 5, Spring Boot 2.0 and the new Spring WebFlux framework. This sandbox is mainly meant to test form binding.
  • thymeleafsandbox-biglist-reactive, using Spring 5, Spring Boot 2.0 and the new Spring WebFlux framework. This sandbox is meant to test the rendering of large amounts of data.
  • thymeleafsandbox-sse-webflux, using Spring 5, Spring Boot 2.0 and the new Spring WebFlux framework. This sandbox is meant to test the rendering of Server-Sent Events (SSE) directly in HTML (no need for JSON parsing at the browser).

Regards,
Daniel.

Reply | Threaded
Open this post in threaded view
|

Re: Thymeleaf 3.0.10 JUST PUBLISHED

Andrei Arkaev
Sadly restricted expressions totally broke backward compartibility.
My th:onclick-expressions throws exceptions now
And no options to switch it off for a while

Only variable expressions returning numbers or booleans are allowed in this context, any other datatypes are not trusted in the context of this expression, including Strings or any other object that could be rendered as a text literal. A typical case is HTML attributes for event handlers (e.g. "onload"), in which textual data from variables should better be output to "data-*" attributes and then read from the event handler.
Reply | Threaded
Open this post in threaded view
|

Re: Thymeleaf 3.0.10 JUST PUBLISHED

danielfernandez
Administrator
This is a security feature that should never be disabled. However, please note that there is a safe workaround (which is actually the right way to pass data to an event handler) by means of the use of "data-*" attributes and "this.getAttribute(...)" at the event handler, as pointed in the exception message.

For more detail, see this ticket: https://github.com/thymeleaf/thymeleaf/issues/705