In other words, how can I combine propagation="none" with @Begin in a single s:link?
In other words, how can I combine propagation="end" with @Begin in a single s:link?
I tried adding both @Begin and @End in the same method, but that only had the effect of beginning first, and the ending (and I want to end first, and then begin).
, combined with @Begin (you need it on your action), you cannot have both defined on s:link. I think that combination works well.
Alternatively to @Begin you can define the beginning of the conversation in pages.xml:
<page view-id="bla.xhtml"> <begin-conversation/> ...
Ok with propagation none you don't explicitely end the conversation but it will timeout much faster because the previous conversation is now in the background. As an added bonus if the user changes his mind he can go back to the previous link with the conversational state still active (using the conversation switcher)
More on conversation timeout:
I don't think you can achieve end-begin cycle with a single click, unless you end the conversation then redirect, in the redirect you begin a new conversation.. Not sure if that would work but it sounds feasible.
I celebrated to soon, because, it works only if I just clicked the menu, but, after (one or) some redirects inside of the conversation if I click the menu I get a org.jboss.seam.NoConversation message and get redirected into the no-conversation-view-id instead of the target page of the menu.
So I guess there should be a better way... Is there?
Mmm, now it is worse, I need to have a no-conversation-view-id and conversation-required="true" in the page directly reference by the menu (it makes no sense to visit that page without a conversation) but, if I do that, the combinacion of propagation="none" and @Begin only works every other time (1 click works, 2nd click redirects to no-conversation-view-id, 3rd works... and so on)
Trying playing with the Conversation api ie. Conversation.instance().end() and Conversation.instance().being() You'd probably want to end before redirect and then begin a new one.
Once you are outside a conversation with (propagation=
none) you cannot go back to that particular conversation simply by clicking back the same link.
You need something a bit more sophisticated. You can use the conversation switcher: 7.9.3. The conversation switcher
Your goal is to run one parallel conversation per link in your side menu right ? I'm not sure how you want to redesign the app to use the conversation switcher but that would certainly change the usage pattern.
For the moment I do not want to go back to a particular conversation, I just want to go to a new one.
But if I use propagation="none" and @Begin and the target page has conversation-required="true" and no-conversation-view-id instead of showing me the target page it will redirect me to the no-conversation-view-id (but not always, it works correctly the second time if I click twice)
BTW I am not using the conversation switcher because, as I posted before, I still do not want to return to a particular conversation, I just want new one, but I am starting to think that either conversation-required="true" is or conversations themselves are...
Mmmm could the problem be becuse the menu is included using facelets (I am not using html frames or iframes), and therefore since the menu is in a page that has conversation-required="true" but it calls propagation="none" it produces some kind of weird conflict? In other words maybe the problem is that:
You can not call a link with propagation="none" linked to an action with @Begin from a page with conversation-required="true" to a page with conversation-required="true" because it will only work after you have been redirected to the the no-conversation-view
Is that true? Is that the expected behavior?
I'm not sure what is expected behavior in this case. Have you tried lifting the conversation-required=
truejust to see what happens?
Maybe its just an issue with the lifecycle, built-in page attribute logic gets executed before your action. If conversation-required=true checks for the presence of a long-running conversation it will fail because propagation=none was handled and @Begin was not processed yet.
I'll test that ASAP.
Do you agree with me that if removing conversation-required="true" fixes the problem, then that means that conversation-required="true" is buggy?
The other problem is that without a conversation, those pages should not be visited... but if can not use conversation-required="true"... what should I do?
Yes, if I remove conversation-required="true" everything seems to work as expected...
Any recommendations on how to implement a properly working replacement for conversation-required="true"?
You can probably file a JIRA with a reproducible testcase, the conversation-required=
truebehavior appears to be buggy like you said.
You can control access to your page through the page rule in pages.xml so if you put
<page > <begin-conversation />
you are guaranteed to have a new conversation anytime you access that page, therefore no need to enforce it with conversation-required=
Maybe, but the thing is that all the menu options basically point to the same page (and store some information in the conversation that reconfigures some dynamic forms inside the "wizard-like" (not really a wizard) interaction that starts there.
So I don't want anyone visiting this page unless it visits it clicking an option in the menu. Any recommendations on how can I achieve that?