I consider to create an alternative solution, because I don't have any ideas about this problem...
could you paste a code snippet of your test.page.xml so that it's easier to reproduce the problem?
Thanks for replay. Sample of test.page.xml is presented below
<?xml version="1.0" encoding="UTF-8"?>
<begin-conversation join="true" />
Actually yes, conversationPropagation request param is handled before page metadata (conversation-required and no-conversation-view-id), whereas conversation control (begin-conversation) is performed afer page metadata. However I'm not sure I'm following you... If you want to begin conversation while entering the page (begin-conversation) why the redirect requirement? Could you describe your use case more thoroughly?
I don't want to start new conversation entering on this page. I would like to join to an existing conversation. Tag <begin-conversation join="true" /> is meaningless. If you remove this tag you will get the same effect.
In my opinion handling conversationPropagation request param before these conversation page metadata is incorrect. If you have conversationPropagation param in url, then conversation-required in page metadata is meaningless. Conversation will be always available for this page
If you don't want to start a new conversation when entering the page, do not use conversationPropagation=join or conversationPropagation=nest. Both are "sub-set" of "begin". In other words join = if a conversation is already active, join the existing one, otherwise begin new; nested = if a conversation is already active, begin a nested conversation.
Hope that helps..
Ok, but it is workaround:)
But if you want to give opportunity to decide about kind of conversation to caller (not page developer), you don't have passibility to do that. For example: Page contains some common functionalities, and can be redirected to from many places in an application. Conversation on this page should be required,in some cases better conversation will be nest, in others join, so developer of this page need to give opportunity to somewhere else what kind of conversation a caller needs. Developer isn't able to use mechanism, i mentioned at the beginning, to make this solution...in my opinion, should be able. Don't you share my point of view?
This situation is not predicted by designers of framework and I need to write another solution of this problem...something like you mentioned in previous post
Hm, I don't think it's a workaround just a design question. Anyway you could always use custom page actions and request parameters to do any logic you require :-).