Package org.thymeleaf.spring5.view.reactive

Class ThymeleafReactiveViewResolver

  • All Implemented Interfaces:
    org.springframework.beans.factory.Aware, org.springframework.context.ApplicationContextAware, org.springframework.core.Ordered, org.springframework.web.reactive.result.view.ViewResolver
    public class ThymeleafReactiveViewResolver
extends org.springframework.web.reactive.result.view.ViewResolverSupport
implements org.springframework.web.reactive.result.view.ViewResolver, org.springframework.context.ApplicationContextAware

    Implementation of the Spring WebFlux ViewResolver interface.

    View resolvers execute after the controller ends its execution. They receive the name of the view to be processed and are in charge of creating (and configuring) the corresponding View object for it.

    The View implementations managed by this class are of type ThymeleafReactiveView.

    In Spring WebFlux applications, Thymeleaf has three modes of operation depending on whether a limit has been set for the output chunk size and/or data-driver context variables have been specified:

    • FULL, when no limit for max chunk size is established (setResponseMaxChunkSizeBytes(int)) and no data-driver context variable has been specified. All template output will be generated in memory as a single chunk (a single DataBuffer object) and then sent to the server's output channels. In this mode, the Thymeleaf template engine works unthrottled, which may benefit performance in some scenarios with small templates, at the cost of a higher memory consumption.
    • CHUNKED, when a limit for max chunk size is established (setResponseMaxChunkSizeBytes(int)) but no data-driver context variable has been specified. Template output will be generated in chunks of a size equal or less than the specified limit (in bytes) and then sent to the server's output channels. After each chunk is emitted, the template engine will stop (thanks to its throttling mechanism), and wait for the server to request more chunks by means of reactive backpressure. Note this mechanism works single-threaded. When using this execution mode, the response will be configured by this ViewResolver so that each output chunk emitted provokes a flush operation at the server output channels (so that partial content is sent to the browser/client).
    • DATA-DRIVEN, when a data-driver variable has been specified at the context (by implementing IReactiveDataDriverContextVariable). This variable is expected to contain a data stream (usually in the shape of a Publisher that Thymeleaf will consume, creating markup output as data is streamed from this data-driver and letting the output channels throttle template engine execution by means of back-pressure. When working in this mode, the response will be configured by this ViewResolver so that the server output channels are flushed after each engine execution (which will happen for each buffer (of configurable size) of elements collected from the data-driver stream. Additionally, if a value has been set for this responseMaxChunkSizeBytes property, the emitted DataBuffer output chunks will never exceed this size, and therefore more than one chunk could be emitted for each buffer of data-driver elements.

    Also note that the properties set by means of setFullModeViewNames(String[]) and setChunkedModeViewNames(String[]) also influence and fine-tune which templates are executed in FULL or CHUNKED mode (they have no effect on DATA-DRIVEN).

    Also note that ThymeleafReactiveView objects can be specifically configured to be executed in CHUNKED mode by instantiating prototypes of them for the desired view names and setting a per-view max chunk size by means of ThymeleafReactiveView.setResponseMaxChunkSizeBytes(int). If this is set to Integer.MAX_VALUE, they will be effectively configured to execute in FULL mode. This per-view setting will always have higher precedence than the one performed at the ViewResolver level.

    Since:
    3.0.3
    Author:
    Daniel Fernández
    See Also:
    ThymeleafReactiveView, ISpringWebFluxTemplateEngine

    • Field Summary

      Fields 
      Modifier and Type Field Description
      static String FORWARD_URL_PREFIX  
      static String REDIRECT_URL_PREFIX
      Prefix to be used in view names (returned by controllers) for specifying an HTTP redirect.

      • Fields inherited from class org.springframework.web.reactive.result.view.ViewResolverSupport

        DEFAULT_CONTENT_TYPE

      • Fields inherited from interface org.springframework.core.Ordered

        HIGHEST_PRECEDENCE, LOWEST_PRECEDENCE

    • Method Summary

      All Methods Instance Methods Concrete Methods 
      Modifier and Type Method Description
      void addStaticVariable​(String name, Object value)
      Add a new static variable.
      protected boolean canHandle​(String viewName, Locale locale)  
      boolean getAlwaysProcessRedirectAndForward()
      Return whether this view resolver should always process forwards and redirects independently of the value of the viewNames property.
      org.springframework.context.ApplicationContext getApplicationContext()  
      String[] getChunkedModeViewNames()
      Return the set of name patterns that will be applied to determine whether a view is to be processed in CHUNKED mode (assuming a maximum response chunk size has been defined).
      String[] getExcludedViewNames()
      Returns the names of views –patterns, in fact– that cannot be handled by this view resolver.
      String[] getFullModeViewNames()
      Returns the set of name patterns that will be applied to determine whether a view is to be processed in FULL mode even if a maximum response chunk size has been defined.
      int getOrder()
      Returns the order in which this view resolver will be queried.
      Function<String,​org.springframework.web.reactive.result.view.RedirectView> getRedirectViewProvider()
      Returns the provider function for creating RedirectView instances when a redirect request is passed to the view resolver.
      int getResponseMaxChunkSizeBytes()
      Return the maximum size (in bytes) allowed for the chunks (DataBuffer) that are produced by the Thymeleaf engine and passed to the server as output.
      Map<String,​Object> getStaticVariables()
      Return the static variables, which will be available at the context every time a view resolved by this ViewResolver is processed.
      ISpringWebFluxTemplateEngine getTemplateEngine()
      Returns the Thymeleaf template engine instance (implementation of ISpringWebFluxTemplateEngine to be used for the execution of templates.
      protected Class<? extends ThymeleafReactiveView> getViewClass()  
      String[] getViewNames()
      Return the set of name patterns that will applied to determine whether a view name returned by a controller will be resolved by this resolver or not.
      protected reactor.core.publisher.Mono<org.springframework.web.reactive.result.view.View> loadView​(String viewName, Locale locale)  
      reactor.core.publisher.Mono<org.springframework.web.reactive.result.view.View> resolveViewName​(String viewName, Locale locale)  
      void setAlwaysProcessRedirectAndForward​(boolean alwaysProcessRedirectAndForward)
      Set whether this view resolver should always process forwards and redirects independently of the value of the viewNames property.
      void setApplicationContext​(org.springframework.context.ApplicationContext applicationContext)  
      void setChunkedModeViewNames​(String[] chunkedModeViewNames)
      Specify a set of name patterns that will be applied to determine whether a view is to be processed in CHUNKED mode (assuming a maximum response chunk size has been defined).
      void setExcludedViewNames​(String[] excludedViewNames)
      Specify names of views –patterns, in fact– that cannot be handled by this view resolver.
      void setFullModeViewNames​(String[] fullModeViewNames)
      Specify a set of name patterns that be will applied to determine whether a view is to be processed in FULL mode even if a maximum response chunk size has been defined.
      void setOrder​(int order)
      Specify the order in which this view resolver will be queried.
      void setRedirectViewProvider​(Function<String,​org.springframework.web.reactive.result.view.RedirectView> redirectViewProvider)
      Sets the provider function for creating RedirectView instances when a redirect request is passed to the view resolver.
      void setResponseMaxChunkSizeBytes​(int responseMaxChunkSizeBytes)
      Set the maximum size (in bytes) allowed for the chunks (DataBuffer) that are produced by the Thymeleaf engine and passed to the server as output.
      void setStaticVariables​(Map<String,​?> variables)
      Sets a set of static variables, which will be available at the context every time a view resolved by this ViewResolver is processed.
      void setTemplateEngine​(ISpringWebFluxTemplateEngine templateEngine)
      Set the template engine object (implementation of ISpringWebFluxTemplateEngine to be used for processing templates.
      void setViewClass​(Class<? extends ThymeleafReactiveView> viewClass)
      Set the view class that should be used to create views.
      void setViewNames​(String[] viewNames)
      Specify a set of name patterns that will applied to determine whether a view name returned by a controller will be resolved by this resolver or not.
      protected boolean shouldUseChunkedExecution​(String viewName)  

      • Methods inherited from class org.springframework.web.reactive.result.view.ViewResolverSupport

        getDefaultCharset, getSupportedMediaTypes, setDefaultCharset, setSupportedMediaTypes

    • Field Detail

      • REDIRECT_URL_PREFIX

        public static final String REDIRECT_URL_PREFIX

        Prefix to be used in view names (returned by controllers) for specifying an HTTP redirect.

        Value: redirect:

        See Also:
        Constant Field Values

    • Constructor Detail

      • ThymeleafReactiveViewResolver

        public ThymeleafReactiveViewResolver()

        Create an instance of ThymeleafReactiveViewResolver.

    • Method Detail

      • setApplicationContext

        public void setApplicationContext​(org.springframework.context.ApplicationContext applicationContext)
                           throws org.springframework.beans.BeansException
        Specified by:
        setApplicationContext in interface org.springframework.context.ApplicationContextAware
        Throws:
        org.springframework.beans.BeansException

      • getApplicationContext

        public org.springframework.context.ApplicationContext getApplicationContext()

      • setViewClass

        public void setViewClass​(Class<? extends ThymeleafReactiveView> viewClass)

        Set the view class that should be used to create views. This must be a subclass of ThymeleafReactiveView.

        Parameters:
        viewClass - class that is assignable to the required view class (by default, ThymeleafReactiveView).

      • getTemplateEngine

        public ISpringWebFluxTemplateEngine getTemplateEngine()

        Returns the Thymeleaf template engine instance (implementation of ISpringWebFluxTemplateEngine to be used for the execution of templates.

        Returns:
        the template engine being used for processing templates.

      • getStaticVariables

        public Map<String,​Object> getStaticVariables()

        Return the static variables, which will be available at the context every time a view resolved by this ViewResolver is processed.

        These static variables are added to the context by the view resolver before every view is processed, so that they can be referenced from the context like any other context variables, for example: ${myStaticVar}.

        Returns:
        the map of static variables to be set into views' execution.

      • addStaticVariable

        public void addStaticVariable​(String name,
                              Object value)

        Add a new static variable.

        These static variables are added to the context by the view resolver before every view is processed, so that they can be referenced from the context like any other context variables, for example: ${myStaticVar}.

        Parameters:
        name - the name of the static variable
        value - the value of the static variable

      • setStaticVariables

        public void setStaticVariables​(Map<String,​?> variables)

        Sets a set of static variables, which will be available at the context every time a view resolved by this ViewResolver is processed.

        This method does not overwrite the existing static variables, it simply adds the ones specify to any variables already registered.

        These static variables are added to the context by the view resolver before every view is processed, so that they can be referenced from the context like any other context variables, for example: ${myStaticVar}.

        Parameters:
        variables - the set of variables to be added.

      • setOrder

        public void setOrder​(int order)

        Specify the order in which this view resolver will be queried.

        Spring Web applications can have several view resolvers configured, and this order property established the order in which they will be queried for view resolution.

        Overrides:
        setOrder in class org.springframework.web.reactive.result.view.ViewResolverSupport
        Parameters:
        order - the order in which this view resolver will be asked to resolve the view.

      • getOrder

        public int getOrder()

        Returns the order in which this view resolver will be queried.

        Spring Web applications can have several view resolvers configured, and this order property established the order in which they will be queried for view resolution.

        Specified by:
        getOrder in interface org.springframework.core.Ordered
        Overrides:
        getOrder in class org.springframework.web.reactive.result.view.ViewResolverSupport
        Returns:
        the order

      • setRedirectViewProvider

        public void setRedirectViewProvider​(Function<String,​org.springframework.web.reactive.result.view.RedirectView> redirectViewProvider)

        Sets the provider function for creating RedirectView instances when a redirect request is passed to the view resolver.

        Note the parameter specified to the function will be the URL of the redirect (as specified in the view name returned by the controller, without the redirect: prefix).

        Parameters:
        redirectViewProvider - the redirect-view provider function.

      • getRedirectViewProvider

        public Function<String,​org.springframework.web.reactive.result.view.RedirectView> getRedirectViewProvider()

        Returns the provider function for creating RedirectView instances when a redirect request is passed to the view resolver.

        Note the parameter specified to the function will be the URL of the redirect (as specified in the view name returned by the controller, without the redirect: prefix).

        Returns:
        the redirect-view provider function.

      • setAlwaysProcessRedirectAndForward

        public void setAlwaysProcessRedirectAndForward​(boolean alwaysProcessRedirectAndForward)

        Set whether this view resolver should always process forwards and redirects independently of the value of the viewNames property.

        When this flag is set to true (default value), any view name that starts with the redirect: or forward: prefixes will be resolved by this ViewResolver even if the view names would not match what is established at the viewNames property.

        Note that the behaviour of resolving view names with these prefixes is exactly the same with this flag set to true or false (perform an HTTP redirect or forward to an internal resource). The only difference is whether the prefixes have to be explicitly specified at viewNames or not.

        Default value is true.

        Parameters:
        alwaysProcessRedirectAndForward - true if redirects and forwards are always processed, false if this will depend on what is established at the viewNames property.

      • getAlwaysProcessRedirectAndForward

        public boolean getAlwaysProcessRedirectAndForward()

        Return whether this view resolver should always process forwards and redirects independently of the value of the viewNames property.

        When this flag is set to true (default value), any view name that starts with the redirect: or forward: prefixes will be resolved by this ViewResolver even if the view names would not match what is established at the viewNames property.

        Note that the behaviour of resolving view names with these prefixes is exactly the same with this flag set to true or false (perform an HTTP redirect or forward to an internal resource). The only difference is whether the prefixes have to be explicitly specified at viewNames or not.

        Default value is true.

        Returns:
        whether redirects and forwards will be always processed by this view resolver or else only when they are matched by the viewNames property.

      • setResponseMaxChunkSizeBytes

        public void setResponseMaxChunkSizeBytes​(int responseMaxChunkSizeBytes)

        Set the maximum size (in bytes) allowed for the chunks (DataBuffer) that are produced by the Thymeleaf engine and passed to the server as output.

        In Spring WebFlux applications, Thymeleaf has three modes of operation depending on whether a limit has been set for the output chunk size and/or data-driver context variables have been specified:

        • FULL, when no limit for max chunk size is established and no data-driver context variable has been specified. All template output will be generated in memory as a single chunk (a single DataBuffer object) and then sent to the server's output channels. In this mode, the Thymeleaf template engine works unthrottled, which may benefit performance in some scenarios with small templates, at the cost of a higher memory consumption.
        • CHUNKED, when a limit for max chunk size is established but no data-driver context variable has been specified. Template output will be generated in chunks of a size equal or less than the specified limit (in bytes) and then sent to the server's output channels. After each chunk is emitted, the template engine will stop (thanks to its throttling mechanism), and wait for the server to request more chunks by means of reactive backpressure. Note this mechanism works single-threaded. When using this execution mode, the response will be configured by this ViewResolver so that each output chunk emitted provokes a flush operation at the server output channels (so that partial content is sent to the browser/client).
        • DATA-DRIVEN, when a data-driver variable has been specified at the context (implementing IReactiveDataDriverContextVariable). This variable is expected to contain a data stream (usually in the shape of a Publisher that Thymeleaf will consume, creating markup output as data is streamed from this data-driver and letting the output channels throttle template engine execution by means of back-pressure. When working in this mode, the response will be configured by this ViewResolver so that the server output channels are flushed after each engine execution (which will happen for each buffer (of configurable size) of elements collected from the data-driver stream. Additionally, if a value has been set for this responseMaxChunkSizeBytes property, the emitted DataBuffer output chunks will never exceed this size, and therefore more than one chunk could be emitted for each buffer of data-driver elements.

        Also note that the properties set by means of setFullModeViewNames(String[]) and setChunkedModeViewNames(String[]) also influence and fine-tune which templates are executed in FULL or CHUNKED mode (they have no effect on DATA-DRIVEN).

        If this property is set to -1 or Integer.MAX_VALUE, no size limit will be used. Note also that there is no limit set by default.

        Also note that this parameter will be ignored when returning SSE (Server-Sent Events), as buffer size in such case will adapt to the size of each returned element (plus its SSE metadata).

        Parameters:
        responseMaxChunkSizeBytes - the maximum size in bytes for output chunks (DataBuffer objects), or -1 or Integer.MAX_VALUE if no limit is to be used.

      • getResponseMaxChunkSizeBytes

        public int getResponseMaxChunkSizeBytes()

        Return the maximum size (in bytes) allowed for the chunks (DataBuffer) that are produced by the Thymeleaf engine and passed to the server as output.

        In Spring WebFlux applications, Thymeleaf has three modes of operation depending on whether a limit has been set for the output chunk size and/or data-driver context variables have been specified:

        • FULL, when no limit for max chunk size is established and no data-driver context variable has been specified. All template output will be generated in memory as a single chunk (a single DataBuffer object) and then sent to the server's output channels. In this mode, the Thymeleaf template engine works unthrottled, which may benefit performance in some scenarios with small templates, at the cost of a higher memory consumption.
        • CHUNKED, when a limit for max chunk size is established but no data-driver context variable has been specified. Template output will be generated in chunks of a size equal or less than the specified limit (in bytes) and then sent to the server's output channels. After each chunk is emitted, the template engine will stop (thanks to its throttling mechanism), and wait for the server to request more chunks by means of reactive backpressure. Note this mechanism works single-threaded. When using this execution mode, the response will be configured by this ViewResolver so that each output chunk emitted provokes a flush operation at the server output channels (so that partial content is sent to the browser/client).
        • DATA-DRIVEN, when a data-driver variable has been specified at the context (implementing IReactiveDataDriverContextVariable). This variable is expected to contain a data stream (usually in the shape of a Publisher that Thymeleaf will consume, creating markup output as data is streamed from this data-driver and letting the output channels throttle template engine execution by means of back-pressure. When working in this mode, the response will be configured by this ViewResolver so that the server output channels are flushed after each engine execution (which will happen for each buffer (of configurable size) of elements collected from the data-driver stream. Additionally, if a value has been set for this responseMaxChunkSizeBytes property, the emitted DataBuffer output chunks will never exceed this size, and therefore more than one chunk could be emitted for each buffer of data-driver elements.

        Also note that the properties set by means of setFullModeViewNames(String[]) and setChunkedModeViewNames(String[]) also influence and fine-tune which templates are executed in FULL or CHUNKED mode (they have no effect on DATA-DRIVEN).

        Also note that the properties set by means of setFullModeViewNames(String[]) and setChunkedModeViewNames(String[]) also influence and fine-tune which templates are executed in FULL or CHUNKED mode (they have no effect on DATA-DRIVEN).

        If this property is set to -1 or Integer.MAX_VALUE, no size limit will be used. Note also that there is no limit set by default.

        Also note that this parameter will be ignored when returning SSE (Server-Sent Events), as buffer size in such case will adapt to the size of each returned element (plus its SSE metadata).

        Returns:
        the maximum size in bytes for output chunks (DataBuffer objects), or -1 or Integer.MAX_VALUE if no limit is to be used.

      • setViewNames

        public void setViewNames​(String[] viewNames)

        Specify a set of name patterns that will applied to determine whether a view name returned by a controller will be resolved by this resolver or not.

        In applications configuring several view resolvers –for example, one for Thymeleaf and another one for JSP+JSTL legacy pages–, this property establishes when a view will be considered to be resolved by this view resolver and when Spring should simply ask the next resolver in the chain –according to its order– instead.

        The specified view name patterns can be complete view names, but can also use the * wildcard: "index.*", "user_*", "admin/*", etc.

        Also note that these view name patterns are checked before applying any prefixes or suffixes to the view name, so they should not include these. Usually therefore, you would specify orders/* instead of /WEB-INF/templates/orders/*.html.

        Parameters:
        viewNames - the view names (actually view name patterns)
        See Also:
        PatternMatchUtils.simpleMatch(String[], String)

      • getViewNames

        public String[] getViewNames()

        Return the set of name patterns that will applied to determine whether a view name returned by a controller will be resolved by this resolver or not.

        In applications configuring several view resolvers –for example, one for Thymeleaf and another one for JSP+JSTL legacy pages–, this property establishes when a view will be considered to be resolved by this view resolver and when Spring should simply ask the next resolver in the chain –according to its order– instead.

        The specified view name patterns can be complete view names, but can also use the * wildcard: "index.*", "user_*", "admin/*", etc.

        Also note that these view name patterns are checked before applying any prefixes or suffixes to the view name, so they should not include these. Usually therefore, you would specify orders/* instead of /WEB-INF/templates/orders/*.html.

        Returns:
        the view name patterns
        See Also:
        PatternMatchUtils.simpleMatch(String[], String)

      • setExcludedViewNames

        public void setExcludedViewNames​(String[] excludedViewNames)

        Specify names of views –patterns, in fact– that cannot be handled by this view resolver.

        These patterns can be specified in the same format as those in setViewNames(String[]), but work as an exclusion list.

        Parameters:
        excludedViewNames - the view names to be excluded (actually view name patterns)
        See Also:
        setViewNames(String[]), PatternMatchUtils.simpleMatch(String[], String)

      • getExcludedViewNames

        public String[] getExcludedViewNames()

        Returns the names of views –patterns, in fact– that cannot be handled by this view resolver.

        These patterns can be specified in the same format as those in setViewNames(String[]), but work as an exclusion list.

        Returns:
        the excluded view name patterns
        See Also:
        getViewNames(), PatternMatchUtils.simpleMatch(String[], String)

      • setFullModeViewNames

        public void setFullModeViewNames​(String[] fullModeViewNames)

        Specify a set of name patterns that be will applied to determine whether a view is to be processed in FULL mode even if a maximum response chunk size has been defined.

        When a response maximum chunk size has been set by means of setResponseMaxChunkSizeBytes(int), this parameter allows the possibility to exclude some views from being applied this maximum size and therefore be executed in FULL mode, in just one template engine execution in-memory.

        This is useful when a maximum chunk size has been set but some pages are actually small enough to benefit from the performance gain of executing the template engine unthrottled, even if this means producing the entire output in memory before sending it to the output channels.

        When a response maximum chunk size has not been set by means of setResponseMaxChunkSizeBytes(int), this parameter has no effect at all.

        When a response maximum chunk size has been set by means of setResponseMaxChunkSizeBytes(int), but a value has also been set to the chunkedModeViewNames parameter by means of setChunkedModeViewNames(String[]) method, this parameter has no effect at all, as only the views specified in the latter parameter will be processed in CHUNKED mode.

        Also note that, if a view specified here to be executed as FULL is executed with a data-driver variable included in the model, the DATA-DRIVEN execution mode will be automatically selected instead, and output chunks will be flushed after each execution of the engine for each buffer of elements obtained from the data-driver stream.

        The specified view name patterns can be complete view names, but can also use the * wildcard: "index.*", "user_*", "admin/*", etc.

        Also note that these view name patterns are checked before applying any prefixes or suffixes to the view name, so they should not include these. Usually therefore, you would specify orders/* instead of /WEB-INF/templates/orders/*.html.

        Parameters:
        fullModeViewNames - the view names (actually view name patterns)
        Since:
        3.0.8
        See Also:
        setResponseMaxChunkSizeBytes(int), setChunkedModeViewNames(String[]), PatternMatchUtils.simpleMatch(String[], String)

      • getFullModeViewNames

        public String[] getFullModeViewNames()

        Returns the set of name patterns that will be applied to determine whether a view is to be processed in FULL mode even if a maximum response chunk size has been defined.

        When a response maximum chunk size has been set by means of setResponseMaxChunkSizeBytes(int), this parameter allows the possibility to exclude some views from being applied this maximum size and therefore be executed in FULL mode, in just one template engine execution in-memory.

        This is useful when a maximum chunk size has been set but some pages are actually small enough to benefit from the performance gain of executing the template engine unthrottled, even if this means producing the entire output in memory before sending it to the output channels.

        When a response maximum chunk size has not been set by means of setResponseMaxChunkSizeBytes(int), this parameter has no effect at all.

        When a response maximum chunk size has been set by means of setResponseMaxChunkSizeBytes(int), but a value has also been set to the chunkedModeViewNames parameter by means of setChunkedModeViewNames(String[]) method, this parameter has no effect at all, as only the views specified in the latter parameter will be processed in CHUNKED mode.

        Also note that, if a view specified here to be executed as FULL is executed with a data-driver variable included in the model, the DATA-DRIVEN execution mode will be automatically selected instead, and output chunks will be flushed after each execution of the engine for each buffer of elements obtained from the data-driver stream.

        The specified view name patterns can be complete view names, but can also use the * wildcard: "index.*", "user_*", "admin/*", etc.

        Also note that these view name patterns are checked before applying any prefixes or suffixes to the view name, so they should not include these. Usually therefore, you would specify orders/* instead of /WEB-INF/templates/orders/*.html.

        Returns:
        the view name patterns
        Since:
        3.0.8
        See Also:
        setResponseMaxChunkSizeBytes(int), setChunkedModeViewNames(String[]), PatternMatchUtils.simpleMatch(String[], String)

      • setChunkedModeViewNames

        public void setChunkedModeViewNames​(String[] chunkedModeViewNames)

        Specify a set of name patterns that will be applied to determine whether a view is to be processed in CHUNKED mode (assuming a maximum response chunk size has been defined).

        This parameter only has effect if a maximum response chunk size has been set by means of setResponseMaxChunkSizeBytes(int). If that is the case, then only the views which name matches the patterns specified here will be executed in CHUNKED mode using the maximum output chunk size that has been configured. All other views will be executed in FULL mode.

        This is useful when a maximum chunk size has been set but it is only needed to apply for certain specific views, normally the larger templates in output size.

        When a response maximum chunk size has not been set by means of setResponseMaxChunkSizeBytes(int), this parameter has no effect at all.

        Also note that, if a view specified here to be executed as CHUNKED is executed with a data-driver variable included in the model, the DATA-DRIVEN execution mode will be automatically selected instead, and output chunks will be flushed after each execution of the engine for each buffer of elements obtained from the data-driver stream. But in this case, the maximum chunk size will also apply and, if any of these data-driven chunks exceeds this size, it will be divided into several output chunks.

        The specified view name patterns can be complete view names, but can also use the * wildcard: "index.*", "user_*", "admin/*", etc.

        Also note that these view name patterns are checked before applying any prefixes or suffixes to the view name, so they should not include these. Usually therefore, you would specify orders/* instead of /WEB-INF/templates/orders/*.html.

        Parameters:
        chunkedModeViewNames - the view names (actually view name patterns)
        Since:
        3.0.8
        See Also:
        setResponseMaxChunkSizeBytes(int), setFullModeViewNames(String[]), PatternMatchUtils.simpleMatch(String[], String)

      • getChunkedModeViewNames

        public String[] getChunkedModeViewNames()

        Return the set of name patterns that will be applied to determine whether a view is to be processed in CHUNKED mode (assuming a maximum response chunk size has been defined).

        This parameter only has effect if a maximum response chunk size has been set by means of setResponseMaxChunkSizeBytes(int). If that is the case, then only the views which name matches the patterns specified here will be executed in CHUNKED mode using the maximum output chunk size that has been configured. All other views will be executed in FULL mode.

        This is useful when a maximum chunk size has been set but it is only needed to apply for certain specific views, normally the larger templates in output size.

        When a response maximum chunk size has not been set by means of setResponseMaxChunkSizeBytes(int), this parameter has no effect at all.

        Also note that, if a view specified here to be executed as CHUNKED is executed with a data-driver variable included in the model, the DATA-DRIVEN execution mode will be automatically selected instead, and output chunks will be flushed after each execution of the engine for each buffer of elements obtained from the data-driver stream. But in this case, the maximum chunk size will also apply and, if any of these data-driven chunks exceeds this size, it will be divided into several output chunks.

        The specified view name patterns can be complete view names, but can also use the * wildcard: "index.*", "user_*", "admin/*", etc.

        Also note that these view name patterns are checked before applying any prefixes or suffixes to the view name, so they should not include these. Usually therefore, you would specify orders/* instead of /WEB-INF/templates/orders/*.html.

        Returns:
        the view name patterns
        Since:
        3.0.8
        See Also:
        setResponseMaxChunkSizeBytes(int), setFullModeViewNames(String[]), PatternMatchUtils.simpleMatch(String[], String)

      • canHandle

        protected boolean canHandle​(String viewName,
                            Locale locale)

      • shouldUseChunkedExecution

        protected boolean shouldUseChunkedExecution​(String viewName)

      • resolveViewName

        public reactor.core.publisher.Mono<org.springframework.web.reactive.result.view.View> resolveViewName​(String viewName,
                                                                                                      Locale locale)
        Specified by:
        resolveViewName in interface org.springframework.web.reactive.result.view.ViewResolver

      • loadView

        protected reactor.core.publisher.Mono<org.springframework.web.reactive.result.view.View> loadView​(String viewName,
                                                                                                  Locale locale)