conversation pattern

[codelion]

Been working on this for a while, so this isn't an aimless question.

Face to face I'd ask: "What do you want to hear first, the purpose, or the question(s)?" Let's have the question(s) first.

Questions:

In "6.3. Starting conversations with GET requests" it says "There is also an <end-conversation> element."

From sources or reading I believe to understand end-conversation causes an isLongRunningConversation flag to be set to false. That flag will be acted upon at the end of the render response phase to destroy the conversation context, which then will be considered temporary. Q1: Is that correct?

Now, further and as I hope is right, if on that page I have some link, button, navigation or whatever that has a (why not named s:propagation?) s:conversationPropagaion type="begin" or a propagation="begin" then that begin causes the same isLongRunningConversation flag to be set to true. That flag will be acted upon at the end of the render response phase to store the conversation context, which then will be considered long running. Q2: Is that correct?

If Q1 and Q2 were correct, then if I get into the habit of for each my.xhtml into its my.page.xml to put

<page>
 <end-conversation/>
...

then I'll have an application where conversations in general are ending, except if I am choosing to being one for a link, button, navigation or whatever, which would then only last until the next page, unless I again choose to being one. Q3: That should work?

Q4: There isn't a way of having an application default by

<pages>
 <end-conversation/>
...

or something like it, is there?

The purpose is that I feel more comfortable with ending conversation as default when there are many options to leave a page. E.g. menus in sidebars.

Q5: Will there be a significant difference in how such an application works with the back button?

Q6: If the conversation context gets destroyed, then a page you back button to won't be fully functional, or will it?

I might be willing to live with that side effect.

As an alternative, I'd like a

<page>
 <dont-propagate-conversation/>
...

or a

<pages>
 <dont-propagate-conversation/>
...

which would be different from end-conversation in that it doesn't destroy but keeps around that conversation context, in case one comes back with a back-button. Q7: Any chance we'll get that?

[codelion]

Luckily no one has answered yet. Can't believe I was so confused about this.

I am looking at 6.1 Seam's conversation model and at JEE5 Tutorial's JavaServer Faces Standard Request-Response Life Cycle again and at my own pages.

I'll be back, I hope, reporting what finally works for us.

[codelion]

I think my trip down confusion road started when we used s:link instead of h:outputLink for menu items that shouldn't have propagate the current conversation.

Moral of the story: For your general purpose links to anything, stuff that isn't meant to propagate a conversation, don't use an unadorned s:link. Either use s:link with propagation="none" or use h:outputLink.

Am I finally getting the mainstream thinking on this topic?

[gavin.king]

That is the correct way, yes.