Hi
Yes, wicket usually handles such things internally, saving you the
overhead of multiple redirects. However, if you need to modify cookie
data and you must rely on getting these infos back in the following
request, you need to force a round trip to the client using
setRedirect(true).
HOWEVER you might well run into trouble with that too, since the default
strategy of wicket is to render the next page while still in the context
of the previous one, then actually send the redirect and if the next
request comes in, it just streams the cached page back. You can change
the strategy used somewhere not to use those buffers, but this might
have even other effects.. So such a situation is very tricky and you
need to be well aware of that pre-rendering and buffering of the next
page...
Matt
On 2011-04-21 09:10, Gabriel Teris wrote:
Hi,
I am quite new to wicket, and I am trying to better understand how the requests
are handled.
My problem is this:
I have a landing page in my application, where I check if the session is a
correct one(I have a parameter called sessionId which dictates the user's
session). If the session is null, I create a cookie with the given parameter
value, and if the session has an unexpected id I invalidate it and create a new
cookie (as above).
Cookies are activated between requests, but as I see in Firebug there is only
one request while displaying 3 pages!
Should I use setRedirect(true) on the page to force redirects? For page
rendering I use the setResponse(Page.class) method, not page instantiation.
I also tried looking for detailed navigation in Wicket in Action and Pro Wicket
books, but I didn't find anything detailed.
smime.p7s
Description: S/MIME Cryptographic Signature
