I've been developing software for over 15 years working in Delphi and now Java. This site is a home for my open source projects, writings, articles and tutorials mainly focusing on Java and Java EE. Andy is a DZone MVB and is not an employee of DZone and has posted 34 posts at DZone. You can read more from them at their website. View Full User Profile

Understanding Nested Conversations

05.04.2011
| 3682 views |
  • submit to reddit

I had a bit of epiphany on the subject of nested conversations the other day when I was thinking about them and thought I’d share. I think nested conversations have been a little misunderstood with people unsure of how to use them, myself included, but I think I have found the best way to think of them.

In summary, nested conversations do for regular conversations what conversations do for session scope. With session scope, you cannot have mutliple instances of a named variable, you have to put each variable instance in its own conversation where it will be unique. However, if you want to have multiple instances of a named variable within the conversation, again, you cannot and you have the same problem you have with the session scope, that variables must be unique. Therefore you have to have each variable in its own nested conversation under the main conversation the same way we had the top level conversation under the session scope.

In some weird web app which lets you pick a person and then put costumes on them, you might have a main page where you select the person, and then in separate browser windows you can pick different outfits for that person. You put the selected person value in a different conversation so the value of #{selectedPerson} is local to the conversation allowing multiple selected people in different browser windows. This overcomes the limitations of the session which allows only one value for #{selectedPerson}

However, if you had that conversation open in multiple windows or tabs so you can compare different costumes on that person, there would only be one value of #{selectedCostume} for the conversation shared between all windows. As you select a costume in one window, it would affect all the other windows as they share the variable in that conversation. Using nested conversations would allow the conversation to have different values for the selected costume under the same parent conversation with the same selected person.

Taking it further you could select the person in the top level conversation, select the costume in the nested conversation, and then you could have multiple windows open with further nested conversation letting you pick different shoes to go with that costume. Also, if you change the person in the top level conversation, it will change the selected person for all windows using that conversation or any of its nested conversations.

I’m not sure there is a great need for nested conversations, I’ve never really used them or found the need and I don’t think users open that many browser windows or tabs to create different logic paths within a conversation. I think it is acceptable to limit the data isolation to a single conversation level.

 

From http://www.andygibson.net/blog/article/understanding-nested-conversations/

Published at DZone with permission of Andy Gibson, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Guillaume Jeudy replied on Fri, 2011/05/06 - 2:11pm

Hey Andy,

 I actually needed nested conversations when implementing a Seam app for a client some years ago. I observed what you just observed in this post. I think it is a very important feature and if it weren't there I would feel like Seam is just a half-baked framework. Is that concept part of CDI JSR ?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.