Problem with attribute conversation-required="true"

[kamiq]

Hello,

I have a very confused problem with conversation propagation and conversation requirement in Seam 2.2. Maybe i wrong understood documentation. The problem is described below.

When I add two attribute to test.page.xml (this xml belongs to xhtml called test.xhtml): conversation-required="true", and no-conversation-view-id="/home.xhtml". According to seam documentation, it's correct configuration if  conversation is required before enter to page. Everytyhing works fine, apart from situation when parameter conversationPropagation=join or conversationPropagation=nest is added to url (in s:link often this attribute is added). Then new conversation is created and user can enter on this page. It looks like conversation is created before checking conversation-required attribute.

Tag <begin-conversation join="true" /> placed inside test.page.xml doesn't create any problems

Is it properly Seam behaviour, that when conversationPropagation is added to url then conversation is created before checking conversation requirement? In my opinion it's huge problem when e.g. conversation timeout appears.

[kamiq]

Any ideas?

I consider to create an alternative solution, because I don't have any ideas about this problem...

[mkouba]

Hi,

could you paste a code snippet of your test.page.xml so that it's easier to reproduce the problem?

[kamiq]

Hi Martin,

Thanks for replay. Sample of test.page.xml is presented below

<?xml version="1.0" encoding="UTF-8"?>

<page xmlns="http://jboss.com/products/seam/pages"

      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

      xsi:schemaLocation="http://jboss.com/products/seam/pages http://jboss.com/products/seam/pages-2.2.xsd"

      conversation-required="true"

      no-conversation-view-id="/login.xhtml">

      <begin-conversation join="true" />

      <action execute="#{authenticator.test()}"/>

</page>

[mkouba]

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?

[kamiq]

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

[mkouba]

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..

[kamiq]

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

[mkouba]

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 :-).