-
1. Re: conversations, propagations etc ... - need explanation
amashtakov Oct 17, 2007 4:31 AM (in response to amashtakov)Sorry, in a prev. message the code for page1.xhtml
should look like this (view attribute was missed by copy/paste):<s:link value="start" view="/page2.xhtml" action="#{conversation.begin}"/>
-
2. Re: conversations, propagations etc ... - need explanation
jacob.orshalick Oct 17, 2007 10:15 AM (in response to amashtakov)This does not throw an exception due to the behavior of an s:link. An s:link initiates a GET request which will only capture parameters passed in the query string (nothing is posted). If you look at the URL generated by your s:link you will see something like the following:
.../page2.seam?conversationPropagation=begin
As you can see, there is no conversationId included in the URL. This would indicate to Seam that a long-running conversation does not exist so promote the temporary conversation to long-running. This could either be a feature or a bug depending on how you look at it. I could imagine situations where this may be a useful feature, but it could definitely be confusing unless you know the finer details.
In the case where you use join="true", the s:link will send the conversationId as part of the query string:
.../page2.seam?conversationId=1&conversationPropagation=join
Obviously if propagation="join" Seam looks for an existing long-running conversation when rendering the s:link (in contrast to propagation="begin"). -
3. Re: conversations, propagations etc ... - need explanation
amashtakov Oct 17, 2007 10:26 AM (in response to amashtakov)Thank you - I've got it.
Meantime I'm trying to explore org.jboss.seam.core.Manager sourcecode
in order to get an answer about how seam determines if long conversation
is active, but with no success (
Seems that restoreConversation() method looks at "conversationIsLongRunningParameter" in request parameters map, but
what about the postback ? ....
I think an answer to such question is a "key" for understanding seam
conversations.
Can anyone explain how does it work ? -
4. Re: conversations, propagations etc ... - need explanation
jacob.orshalick Oct 17, 2007 10:59 AM (in response to amashtakov)Which version of Seam are you using? conversation-is-long-running-parameter is not included in latest (Seam 2.0.0.CR2) due to the addition of conversation-required.
The key to understanding conversations is the conversationId sent with the request. The conversationId is maintained along with the view (as you've discovered) and indicates to Seam what the foreground long-running conversation is. This is why the back-button just seems to work. If the user goes back to a previous view, the conversationId will be sent with that view in the request so our conversation context is restored (if it exists otherwise redirect to no-conversation-view-id).
Feel free to parse the code but the details of how this works should really be transparent if you use the methods of propagation provided i.e. @Begin, s:link, s:conversationPropagation, etc). Understanding the semantics is the key. As long as the appropriate conversationId is sent with the request, your conversation state will be restored.
Hope that helps. -
5. Re: conversations, propagations etc ... - need explanation
amashtakov Oct 17, 2007 11:13 AM (in response to amashtakov)
Which version of Seam are you using? conversation-is-long-running-parameter is not included in latest (Seam 2.0.0.CR2) due to the addition of conversation-required.
I'm using 1.2.1GA
The key to understanding conversations is the conversationId sent with the request. The conversationId is maintained along with the view (as you've discovered) and indicates to Seam what the foreground long-running conversation is.
I noticed two GET parameters [cid] and [clr] and it seems that the second
one is used in order to check whether the conversation is long running or not. But I do not understand how does the postback work - tried to
print out the request parameters but nothing about cid/clr:<c:forEach var="n" items="#{facesContext.externalContext.requestParameterMap}"> #{n.key} = #{n.value}<br/> </c:forEach>
This is why the back-button just seems to work. If the user goes back to a previous view, the conversationId will be sent with that view in the request so our conversation context is restored (if it exists otherwise redirect to no-conversation-view-id).
How does the conversationId sent with that view ?
I checked seam-booking demo with back button - the page is restored, but
seems it's from browser's cache - server.log didn't included an extra request trace.
Understanding the semantics is the key. As long as the appropriate conversationId is sent with the request, your conversation state will be restored.
As a GET parameter ? -
6. Re: conversations, propagations etc ... - need explanation
jacob.orshalick Oct 17, 2007 11:41 AM (in response to amashtakov)"amashtakov" wrote:
I'm using 1.2.1GA
Yes, 1.2.1.GA uses clr (conversation-long-running-parameter="clr").
There are essentially 2 scenarios:
- GET - conversation attributes passed in query string (the situation you are referring to)
- POST - conversation attributes posted with the form not in the query string (handled transparently by Seam but feel free to parse the code to see the finer details)
So if you use an h:commandLink, h:commandButton, etc, a POST will be initiated which will transparently send the values along with the form. Due to this, the browser cached page will include the values along with the form which is why the back button works. -
7. Re: conversations, propagations etc ... - need explanation
amashtakov Oct 17, 2007 1:39 PM (in response to amashtakov)Thank you,
I'm going to experiment tomorrow a bit more (do not have jboss/seam at home yet) - will check back button feature.