This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • Render strategies
Skip to end of metadata
Go to start of metadata

Table of contents

Based on a post to the Wicket-User list by Johan Compagner

> what are render strategies used for? by reading the javadocs I
> always see action part, render part: what is the meaning of these 2?

Action part is the part where the listeners are being called (lets say the Swing Action.actionPerformed() method)

For example the action part is the Link.onClicked() or the Form.onSubmit() (models updated/ database updated)
That action will result in a response page set.

After that we get the rendering/response part. And now the render strategies are kicking in.
You have 3 choices as to how a response page that was set by the action phase will be served to the client

ONE_PASS_RENDER

In the same request (ONE_PASS_RENDER) so the action part and the response part are done in the same http request.
The drawbacks are that the url the user sees is mostly a ugly one (i.e. the get or post of the link/form) and you have the reload button problem where the user can re-submit the things he just submitted.

REDIRECT_TO_RENDER

In a redirect request (REDIRECT_TO_RENDER) so the action part set a response page. The response phase first sets
a redirect url. After the client side redirect (a second http request,) the response page will be served. Reload button problems are fixed by this but all your models are attached and detached once more. Also, listviews can only build their tables in the redirect response phase, so the page structure is changing (or can change) twice for one submit a user made, which is bad for clustering.

REDIRECT_TO_BUFFER (default)

And we have the combination which is the default (REDIRECT_TO_BUFFER). This has the best of both worlds. No reload button problems, because we do a client side redirect, but the rendering of the page itself is already done in the first request and stored in a buffer until the redirect returns, so because of this models are only attached and detached once and listviews only alter pages in one request, not 2.

Which one to use in a cluster

This is the best option for almost all situations except a non-sticky cluster environment because the redirect could then hit a different server from that in which the response buffer is being held. For these, though, the only really viable option is setting 1.

  • No labels