-
1. Re: How bad is unused conversations?
ellenzhao Jul 24, 2007 5:55 PM (in response to emsa)Is @Begin(join = true) what you are looking for?
-
2. Re: How bad is unused conversations?
emsa Jul 24, 2007 5:57 PM (in response to emsa)No - I might have dirty state in the Conversation that a want to get rid of. Also if the user selects the same page/task I want a new, empty, conversation.
-
3. Re: How bad is unused conversations?
gavin.king Jul 24, 2007 6:14 PM (in response to emsa)I think its not usually a big deal, just set a short conversation timeout (you can even reduce it using Conversation.instance().setTimeout()).
But, you need to test performance in your own environment, -
4. Re: How bad is unused conversations?
stephen.friedrich Jul 24, 2007 6:25 PM (in response to emsa)Hm, I'm not sure that I fully grok conversations, but it seems to me that starting conversations whenever a task/page is selected is overkill.
Isn't it sufficient to start a conversation on the first submit after the page is shown ("the first task action")? -
5. Re: How bad is unused conversations?
jcg3 Jul 24, 2007 7:51 PM (in response to emsa)In your menu links, you should do something like this:
<s:link value="Visible Label" view="/SomePage.xhtml" propagation="end" />
That will kill off the old conversation as the new one starts.
This is assuming that you can start the new conversation from the Seam component, or in your pages.xml config.
Play around with it and leverage the debug.seam page to see how conversations are created/destroyed as you use various propagation and conversation settings. -
6. Re: How bad is unused conversations?
azalea Jul 24, 2007 8:52 PM (in response to emsa)Hi
Gavin,
how do you think about controlling the number of the active conversations per user(session)?
That means that the old conversations will be destroyed when the number of the user's active conversations is beyond the maximum number of the conversations per user(session). -
7. Re: How bad is unused conversations?
emsa Jul 25, 2007 3:49 AM (in response to emsa)All very good suggestions and I have cycled through most of them in one way or another.
Hopefully Gavin is right and it will just work(tm) letting the Conversations timeout.
Starting the Conversation at "the first submit" might work in some cases but usually the state (lists of objects etc) is created when the page is first shown not when the first submit from that page occurs.
Using propagation="end" with any form of Conversation Begin in the same request/event will just reuse the same Conversation and not create a new one.
What I basically (think) I'm looking for is a propagation that ends a named/current conversation in a 'before phase', destroying it before doing anything else, and then promotes the new Conversation into a long-running one. -
8. Re: How bad is unused conversations?
denis-karpov Jul 25, 2007 8:43 AM (in response to emsa)Yes it is very important question.
now we have:
begin - marks current not long running conversation to be long running.
end - marks current long running conversation to be not long running.
join - join existing conversation (now it fails if there is no long running conversation, as I remember. Gavin promised to fix it ;-)
nest - begins nested conversation
none - leave the current long running conversation
But what if I want to start a new conversation no matter where I am now? Either I am in long running conversation or in not long running.
Like in this situation with menu bar. When I click menu item I want to start clean new long running conversation. In more strict words, to leave current conversation, to start new one (before render) and to mark a new one as long running.
(I am not sure is it possible now to leave one and start another new conversation inside one request?) -
9. Re: How bad is unused conversations?
stephen.friedrich Jul 25, 2007 9:35 AM (in response to emsa)To further complicate matters:
What one would sometimes want instead is to have a separate long-running conversation for each tab/menu/page, isn't that so?
User starts a task in one page then temporarily switches to another to look up needed information and likes to continue with the original tasks after that? Any idea? -
10. Re: How bad is unused conversations?
emsa Jul 25, 2007 9:53 AM (in response to emsa)"stephen.friedrich" wrote:
To further complicate matters:
What one would sometimes want instead is to have a separate long-running conversation for each tab/menu/page, isn't that so?
This is pretty much covered by "explicit" conversation id (§6.6) and Workspace management (§6.7). -
11. Re: How bad is unused conversations?
stephen.friedrich Jul 25, 2007 10:20 AM (in response to emsa)Hm, I think explicit conversation ids only make sense when the application logic naturally suggests them. (Like using an article id for an article editor - it really makes no sense to edit the very same article in different conversations).
To make matters more concrete: Image a UI that shows a tabbed pane where each tab hosts a possible step of interactions.
So you want each tab to have a conversation of its own. However if you simply assign fixed conversation ids you will loose the ability to open new browser windows/tabs.
There's a lot of documentation how context demarcation technically works, but there is close to none how it it relates to interaction design.
Note that you would not have to think twice about how to implement this in a rich client: Each tab instance would simply holds its model which is "commited" at the final step of the task. -
12. Re: How bad is unused conversations?
jcg3 Jul 25, 2007 10:41 AM (in response to emsa)Couldn't one use the conversationList object, inject it into your java class, and iterate through the conversations -- destroy'ing the ones that are no longer needed?
Not necessarily elegant, but if propagation="end" doesn't actually end the conversation, it seems like an alternative worth exploring. -
13. Re: How bad is unused conversations?
emsa Jul 25, 2007 3:01 PM (in response to emsa)Well you could use conversationList but how do you know what conversations are in use? The user could use several windows so many conversation could be active.
The (only) way do solve this (if it really needs solving) is to extend s:link (or similar) with a new propagation, say, endAndBegin and one extra parameter, conversationIdToEnd.
The server (probably SeamPhaseListener) will do exactly the same as with begin plus that it will set the timeout to 0 or promptly end the Conversation with the conversationIdToEnd.