HiYes, 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
