Interface IReactiveDataDriverContextVariable

All Known Subinterfaces:
IReactiveSSEDataDriverContextVariable
All Known Implementing Classes:
ReactiveDataDriverContextVariable

public interface IReactiveDataDriverContextVariable

Interface to be implemented by context variables wrapping asynchronous objects in the form of reactive data streams which are meant to drive the reactive-friendly execution of a template.

The presence of a variable of this type in the context sets the engine into data-driven mode, and only one of these variables is allowed to appear in the context for template execution.

Using Reactive Streams terminology, this makes Thymeleaf act as a Processor, given it will be a Subscriber to the data-driver stream, and at the same time a Publisher of output buffers (usually containing HTML markup).

Templates executed in data-driven mode are expected to contain some kind iteration on the data-driver variable, normally by means of a th:each attribute. This iteration should be unique. Also note that, if this iteration is not present (or it doesn't end up being executed due to template logic), it is not guaranteed that the data-driven stream will not be consumed anyway -at least partially- depending on the use that the specific server implementation might make of the Reactor's back-pressure mechanism.

Data-driver context variables are required to be multi-valued. Being multi-valued does not mean to necessarily return more than one value, but simply to have the capability to do so. E.g. a Flux object will be considered multi-valued even if it publishes none or just one result, whereas a Mono object will be considered single-valued.

The getBufferSizeElements() property describes the size (in elements) of the buffers that will be created from the data-driver stream before triggering the execution of the template (for each buffer). Normally there is no need to execute the template engine and generate output for each element of data published by the data stream, so this buffering prevents Thymeleaf from executing more times than actually needed.

The ReactiveDataDriverContextVariable class contains a sensible implementation of this interface, directly usable in most scenarios. Example use:


 @RequestMapping("/something")
 public String doSomething(final Model model) {
     final Publisher<Item> data = ...; // This has to be MULTI-VALUED (e.g. Flux)
     model.addAttribute("data", new ReactiveDataDriverContextVariable(data, 100));
     return "view";
 }
 

And then at the template:


 <table>
   <tbody>
     <tr th:each="item : ${data}">
       <td th:text="${item}">some item...</td>
     </tr>
   </tbody>
 </table>
 
Since:
3.0.3
Author:
Daniel Fernández
  • Method Summary

    Modifier and Type
    Method
    Description
    int
    Returns the size (in elements) of the buffers that will be created from the data-driver stream before triggering the execution of the template (for each buffer).
    org.reactivestreams.Publisher<Object>
    getDataStream(org.springframework.core.ReactiveAdapterRegistry reactiveAdapterRegistry)
    Returns the reactive asynchronous object being wrapped, (perhaps) having been re-shaped into a Publisher stream.
  • Method Details

    • getDataStream

      org.reactivestreams.Publisher<Object> getDataStream(org.springframework.core.ReactiveAdapterRegistry reactiveAdapterRegistry)

      Returns the reactive asynchronous object being wrapped, (perhaps) having been re-shaped into a Publisher stream.

      Parameters:
      reactiveAdapterRegistry - the Spring reactive adapter registry that should be used in order to transform other reactive implementations (RxJava, etc.) into Flux. Can be null (no adaptations will be available).
      Returns:
      the asynchronous object (as a Publisher).
    • getBufferSizeElements

      int getBufferSizeElements()

      Returns the size (in elements) of the buffers that will be created from the data-driver stream before triggering the execution of the template (for each buffer).

      Normally there is no need to execute the template engine and generate output for each element of data published by the data stream, so this buffering prevents Thymeleaf from executing more times than actually needed.

      Returns:
      the size (in elements) of the buffers to be created for each (partial) execution of the engine.