basically the advantage being that you always have a GET url that points to
a VIEW in the browser, and never a POST url that points to an ACTION. so if
user presses refresh or back you never see that annoying "submit post
values" popup and pressing refresh never triggers any action as well.
-igor
On 3/9/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> However I admit I don't really understand the REDIRECT_TO_BUFFER
> thing. Can you explain what is the purpose of this?
/**
* 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.
*/
public static final IRequestCycleSettings.RenderStrategy
REDIRECT_TO_BUFFER = new IRequestCycleSettings.RenderStrategy(
"REDIRECT_BUFFER");
It is a variation of the theme that commonly is named 'redirect after
post' in other frameworks, only we do it for everything including
links. And if fact, most frameworks don't even have a default facility
for this, so while it's not a feature that will immediately obvious to
people new to Wicket, it is actually a pretty cool 'selling point'.
There are three options with wicket:
* the default, redirect to buffer, which renders the whole response to
a buffer kept in the application (with a max of three) and immediately
redirect to a request that just streams out that buffer
* redirect to render, which separates the 'action' and 'render' phase
of the request. Not typically recommended, but needed for portlets
* one pass render, which doesn't do any redirect magic. But that means
that you'll have to provide a solution for the redirect after post
thing yourself (if you care, but you should imo).
Eelco
