I'm pretty sure that's the case. Perhaps the best way to think of it is setCookie puts a cookie into the response header and getCookie gets one from the request header.
On Wednesday, May 11, 2005, at 02:27PM, Eric Schneider <[EMAIL PROTECTED]> wrote: >Barry, > >>> The problem is setting the cookie just puts the cookie into the >>> response header. Until the browser makes another request the >>> cookie is not really set. > >Is this really the case? If you set a cookie in a http request, it's >not available in the http response? Because I can confirm that the >cookie was set in the browser when the response comes back (addition >request doesn't seem to be required). > >I'll try the RedirectException, see if that does the trick. > >Thanks for the suggestion. > >e. > > >On May 11, 2005, at 3:01 PM, Barry Books wrote: > >>> From the way you describe your code you are trying to retrieve the >>> cookie in the same request cycle you set it. The problem is >>> setting the cookie just puts the cookie into the response header. >>> Until the browser makes another request the cookie is not really >>> set. You could either hide this feature by also storing the >>> information in the visit object or throw a page redirect exception >>> which would cause the browser to retrieve a new page with the >>> cookie set. >>> >> >> Barry >> >> On Wednesday, May 11, 2005, at 01:46PM, Eric Schneider >> <[EMAIL PROTECTED]> wrote: >> >> >>> Hi, >>> >>> I'm having trouble getting my head around some behavior that I'm >>> seeing. Here's the scenario: >>> >>> I have two components that appear on every page of my application, >>> component A & B. >>> >>> When I start a new Visit to the application, the Home page renders >>> and users can invoke an action on component A that sets a cookie and >>> returns the next page. Based on the value of this cookie some >>> behavior on component B should change when the next page is >>> rendered. Simple enough. >>> >>> The problem I'm having, for whatever reason, component B is not able >>> to retrieve the cookie value on the first render after the cookie is >>> originally set. All subsequent actions (any action, not just the >>> one related to Component A), component B is able to retrieve the >>> cookie successfully. >>> >>> Here's where I get lost trying to figure out how the RequestCycle >>> works. Both components (A & B) implement PageRenderListener and >>> define a pageBeginRender(PageEvent event) method (this is where I >>> attempt get a handle of the cookie). I've added some debugging >>> output to these methods and the results are a bit puzzling. >>> >>> After first action is invoked, the order goes something like this: >>> >>> - Component A: pageBeginRender() is fired >>> - Component B: pageBeginRender() is fired >>> - Cookie is written >>> - Component A: pageBeginRender() is fired (2nd time) >>> - Component B: pageBeginRender() is fired (2nd time) >>> - Attempt to retrieve cookie returns null >>> - Component A: pageBeginRender() is fired (3rd time) >>> - Component B: pageBeginRender() is fired (3rd time) >>> - Additional attempt to retrieve cookie returns null >>> - Next page renders. >>> >>> The any additional request, the cycle's path seems much simpler: >>> >>> - Component A: pageBeginRender() is fired >>> - Component B: pageBeginRender() is fired >>> - Cookie successfully returns >>> >>> Anyone have any advice on what's going on here? >>> >>> Thanks, >>> Eric >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: tapestry-user- >>> [EMAIL PROTECTED] >>> >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
