Interface IReactiveDataDriverContextVariable
- All Known Subinterfaces:
IReactiveSSEDataDriverContextVariable
- All Known Implementing Classes:
ReactiveDataDriverContextVariable
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 TypeMethodDescriptionint
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 aPublisher
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.) intoFlux
. 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.
-