| wicket.settings.IRequestCycleSettings
All known Subclasses: wicket.settings.Settings,
IRequestCycleSettings | public interface IRequestCycleSettings (Code) | | Inteface for request related settings
bufferResponse (defaults to true) - True if the application should
buffer responses. This does require some additional memory, but helps keep
exception displays accurate because the whole rendering process completes
before the page is sent to the user, thus avoiding the possibility of a
partially rendered page.
renderStrategy - Sets in what way the render part of a request is
handled. Basically, there are two different options:
- Direct, ApplicationSettings.ONE_PASS_RENDER. Everything is handled in
one physical request. This is efficient, and is the best option if you want
to do sophisticated clustering. It does not however, shield you from what is
commonly known as the Double submit problem
- Using a redirect. This follows the pattern as described at the serverside and that is commonly known as Redirect
after post. Wicket takes it one step further to do any rendering after a
redirect, so that not only form submits are shielded from the double submit
problem, but also the IRequestListener handlers (that could be e.g. a link
that deletes a row). With this pattern, you have two options to choose from:
- ApplicationSettings.REDIRECT_TO_RENDER. This option first handles the
'action' part of the request, which is either page construction (bookmarkable
pages or the home page) or calling a IRequestListener handler, such as
Link.onClick. When that part is done, a redirect is issued to the render
part, which does all the rendering of the page and its components. Be
aware that this may mean, depending on whether you access any
models in the action part of the request, that attachement and detachement of
some models is done twice for a request.
- ApplicationSettings.REDIRECT_TO_BUFFER. This option handles both the
action- and the render part of the request in one physical request, but
instead of streaming the result to the browser directly, it is kept in
memory, and a redirect is issue to get this buffered result (after which it
is immediately removed). This option currently is the default render
strategy, as it shields you from the double submit problem, while being more
efficient and less error prone regarding to detachable models.
Note that this parameter sets the default behavior, but that you can manually
set whether any redirecting is done by calling method
RequestCycle.setRedirect. Setting the redirect flag when the application is
configured to use ONE_PASS_RENDER, will result in a redirect of type
REDIRECT_TO_RENDER. When the application is configured to use
REDIRECT_TO_RENDER or REDIRECT_TO_BUFFER, setting the redirect flag to false,
will result in that request begin rendered and streamed in one pass.
More documentation is available about each setting in the setter method for
the property.
author: Igor Vaynberg (ivaynberg) |
Inner Class :public static class RenderStrategy extends EnumeratedType | |
ONE_PASS_RENDER | final public static IRequestCycleSettings.RenderStrategy ONE_PASS_RENDER(Code) | | All logical parts of a request (the action and render part) are handled
within the same request. To enable a the client side redirect for a
request, users can set the 'redirect' property of
RequestCycle to
true (getRequestCycle.setRedirect(true)), after which the behavior will
be like RenderStragegy 'REDIRECT_TO_RENDER'.
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 | final public static IRequestCycleSettings.RenderStrategy REDIRECT_TO_BUFFER(Code) | | 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 | final public static IRequestCycleSettings.RenderStrategy REDIRECT_TO_RENDER(Code) | | 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 seperate request by issueing 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. To cancel the client side
redirect for a request, users can set the 'redirect' property of
RequestCycle to false (getRequestCycle.setRedirect(false)).
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 seperate request.
Not only is this less efficient, but this also can mean that within the
same request attachement/ detachement 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
possibily, and should also be aware that for one logical request,
actually two instances of RequestCycle are created and processed.
|
addResponseFilter | void addResponseFilter(IResponseFilter responseFilter)(Code) | | Adds a response filter to the list. Filters are evaluated in the order
they have been added.
Parameters: responseFilter - The IResponseFilter that is added |
getBufferResponse | boolean getBufferResponse()(Code) | | True if this application buffers its responses |
getGatherExtendedBrowserInfo | boolean getGatherExtendedBrowserInfo()(Code) | | Gets whether Wicket should try to get extensive client info by
redirecting to
BrowserInfoPage a page that polls for client capabilities . This
method is used by the default implementation of
WebRequestCycle.newClientInfo , so if that method is overriden,
there is no guarantee this method will be taken into account.
Whether to gather extensive client info |
getResponseFilters | List getResponseFilters()(Code) | | an unmodifiable list of added response filters, null if none |
getResponseRequestEncoding | String getResponseRequestEncoding()(Code) | | In order to do proper form parameter decoding it is important that the
response and the following request have the same encoding. see
http://www.crazysquirrel.com/computing/general/form-encoding.jspx for
additional information.
The request and response encoding |
getTimeout | Duration getTimeout()(Code) | | Gets the time that a request will by default be waiting for the previous
request to be handled before giving up.
The time out |
setBufferResponse | void setBufferResponse(boolean bufferResponse)(Code) | | Parameters: bufferResponse - True if this application should buffer responses. |
setGatherExtendedBrowserInfo | void setGatherExtendedBrowserInfo(boolean gatherExtendedBrowserInfo)(Code) | | Sets whether Wicket should try to get extensive client info by
redirecting to
BrowserInfoPage a page that polls for client capabilities . This
method is used by the default implementation of
WebRequestCycle.newClientInfo , so if that method is overriden,
there is no guarantee this method will be taken into account.
Parameters: gatherExtendedBrowserInfo - Whether to gather extensive client info |
setRenderStrategy | void setRenderStrategy(IRequestCycleSettings.RenderStrategy renderStrategy)(Code) | | Sets in what way the render part of a request is handled. Basically,
there are two different options:
- Direct, ApplicationSettings.ONE_PASS_RENDER. Everything is handled
in one physical request. This is efficient, and is the best option if you
want to do sophisticated clustering. It does not however, shield you from
what is commonly known as the Double submit problem
- Using a redirect. This follows the pattern as described at the serverside and that is commonly known as
Redirect after post. Wicket takes it one step further to do any rendering
after a redirect, so that not only form submits are shielded from the
double submit problem, but also the IRequestListener handlers (that could
be e.g. a link that deletes a row). With this pattern, you have two
options to choose from:
- ApplicationSettings.REDIRECT_TO_RENDER. This option first handles
the 'action' part of the request, which is either page construction
(bookmarkable pages or the home page) or calling a IRequestListener
handler, such as Link.onClick. When that part is done, a redirect is
issued to the render part, which does all the rendering of the page and
its components. Be aware that this may mean, depending
on whether you access any models in the action part of the request, that
attachement and detachement of some models is done twice for a request.
- ApplicationSettings.REDIRECT_TO_BUFFER. This option handles both the
action- and the render part of the request in one physical request, but
instead of streaming the result to the browser directly, it is kept in
memory, and a redirect is issue to get this buffered result (after which
it is immediately removed). This option currently is the default render
strategy, as it shields you from the double submit problem, while being
more efficient and less error prone regarding to detachable models.
Note that this parameter sets the default behavior, but that you can
manually set whether any redirecting is done by calling method
RequestCycle.setRedirect. Setting the redirect flag when the application
is configured to use ONE_PASS_RENDER, will result in a redirect of type
REDIRECT_TO_RENDER. When the application is configured to use
REDIRECT_TO_RENDER or REDIRECT_TO_BUFFER, setting the redirect flag to
false, will result in that request begin rendered and streamed in one
pass.
Parameters: renderStrategy - the render strategy that should be used by default. |
setResponseRequestEncoding | void setResponseRequestEncoding(String responseRequestEncoding)(Code) | | In order to do proper form parameter decoding it is important that the
response and the following request have the same encoding. see
http://www.crazysquirrel.com/computing/general/form-encoding.jspx for
additional information.
Default encoding: UTF-8
Parameters: responseRequestEncoding - The request and response encoding to be used. |
setTimeout | void setTimeout(Duration timeout)(Code) | | Sets the time that a request will by default be waiting for the previous
request to be handled before giving up.
Parameters: timeout - |
|
|