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
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 expl
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
"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).
View the
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 ta
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. Ga
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) i
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).
View the origi
In your menu links, you should do something like this:
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
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")?
View the original post :
http://www.
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,
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067205#406
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.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067199#4067199
Reply to the post :
http://www.jboss.com
Is @Begin(join = true) what you are looking for?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067195#4067195
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067195
___
jboss-
13 matches
Mail list logo
