[CONF] Apache Wicket: Render strategies (page edited)

[confluence]

Page Edited : WICKET : Render strategies Render strategies has been edited by Martijn Dashorst (Apr 24, 2007). (View changes) Content: Table of contents ONE_PASS_RENDER REDIRECT_TO_RENDER REDIRECT_TO_BUFFER (default) 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. 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.

Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request

Unsubscribe or edit your notifications preferences