Package org.apache.wicket.settings

Enum RequestCycleSettings.RenderStrategy

    • Enum Constant Detail

      • ONE_PASS_RENDER

        public static final RequestCycleSettings.RenderStrategy ONE_PASS_RENDER
        All logical parts of a request (the action and render part) are handled within the same request.

        This strategy is more efficient than the 'REDIRECT_TO_RENDER' strategy, and doesn't have some of the potential problems of it, it also does not solve the double submit problem. It is however the best option to use when you want to do sophisticated (non-sticky session) clustering.

      • REDIRECT_TO_BUFFER

        public static final RequestCycleSettings.RenderStrategy REDIRECT_TO_BUFFER
        All logical parts of a request (the action and render part) are handled within the same request, but instead of streaming the render result to the browser directly, the result is cached on the server. A client side redirect command is issued to the browser specifically to render this request.

      • REDIRECT_TO_RENDER

        public static final RequestCycleSettings.RenderStrategy REDIRECT_TO_RENDER
        The render part of a request (opposed to the 'action part' which is either the construction of a bookmarkable page or the execution of a IRequestListener handler) is handled by a separate request by issuing a redirect request to the browser. This is commonly known as the 'redirect after submit' pattern, though in our case, we use it for GET and POST requests instead of just the POST requests.

        This pattern solves the 'refresh' problem. While it is a common feature of browsers to refresh/ reload a web page, this results in problems in many dynamic web applications. For example, when you have a link with an event handler that e.g. deletes a row from a list, you usually want to ignore refresh requests after that link is clicked on. By using this strategy, the refresh request only results in the re-rendering of the page without executing the event handler again.

        Though it solves the refresh problem, it introduces potential problems, as the request that is logically one, are actually two separate request. Not only is this less efficient, but this also can mean that within the same request attachment/ detachment of models is done twice (in case you use models in the bookmarkable page constructors and IRequestListener handlers). If you use this strategy, you should be aware of this possibility, and should also be aware that for one logical request, actually two instances of RequestCycle are created and processed.

        Also, even with this strategy set, it is ignored for instances of BookmarkableListenerRequestHandler, because otherwise they wouldn't be bookmarkable.

    • Method Detail

      • values

        public static RequestCycleSettings.RenderStrategy[] values()
        Returns an array containing the constants of this enum type, in the order they are declared. This method may be used to iterate over the constants as follows: 
        for (RequestCycleSettings.RenderStrategy c : RequestCycleSettings.RenderStrategy.values())
    System.out.println(c);
        Returns:
        an array containing the constants of this enum type, in the order they are declared

      • valueOf

        public static RequestCycleSettings.RenderStrategy valueOf​(String name)
        Returns the enum constant of this type with the specified name. The string must match exactly an identifier used to declare an enum constant in this type. (Extraneous whitespace characters are not permitted.)
        Parameters:
        name - the name of the enum constant to be returned.
        Returns:
        the enum constant with the specified name
        Throws:
        IllegalArgumentException - if this enum type has no constant with the specified name
        NullPointerException - if the argument is null