-
1. Re: end-conversation
gavin.king Feb 13, 2007 12:38 PM (in response to vk101)If you set beforeRedirect=true, during a request which ends in a browser redirect, the conversation context is destroyed during the initial request (before the redirected request) meaning that you won't have access to conversation-scoped state when the next page is rendered (you'll lose all the FacesMessages, etc). OTOH, you also won't see the ugly "?cid=4" crap in the URL :-)
-
2. Re: end-conversation
vk101 Feb 13, 2007 1:48 PM (in response to vk101)Oh...I didn't realize the behavior under "true" wasn't default behavior.
If there wasn't a redirect, wouldn't the conversation be over on the re-rendered page (and if you did a GET for something else the conversation would not come with it)? Then how can a conversation propagate across a GET that happens immediately after the render in the form of a redirect?
Confused...whatever...I'll just memorize that. -
3. Re: end-conversation
gavin.king Feb 13, 2007 2:01 PM (in response to vk101)Re-read the documentation, and closely observe the behavior of the booking demo. By default, Seam propagates all conversations across redirects.
(Yes, even temporary conversations!)
(Yes, even conversations that you already @Ended.)
Which is almost always what you want, in practice. -
4. Re: end-conversation
gavin.king Feb 13, 2007 2:02 PM (in response to vk101)In fact, you are probably already taking advantage of this behavior in you app, without realizing it.
-
5. Re: end-conversation
vk101 Feb 21, 2007 12:47 AM (in response to vk101)I just noticed that you can put end-conversation underneath a pages element. Would that end the conversation...on page load? Or would it mark the conversation as temporary, meaning that everything that happens in that page would still be in the same conversation?
Does setting beforeRedirect to true change whatever the above behavior is? -
6. Re: end-conversation
gavin.king Feb 21, 2007 10:55 AM (in response to vk101)It means demote a long-running conversation to temporary.
But since this stuff occurs just before render response, before-redirect has no effect when it occurs in this place.