anonymous wrote : | Specifically: Why do you need join="true" if you just have ended the previous conversation with propagation="end"? | He talked about starting a new one with join=true. The join=true bit ensures that you don't start a new one each time the page is rendered. maku01 : Regarding the conversation tags in pages.xml, I believe (and I could be wrong on this) that you need to rephrase the constant to something like : | <conversation name="PartnerMaintConv" | parameter-name="cid" | parameter-value="#{PartnerMaintConv}"/> | The constant should force a reuse of the conversation that you are looking for, although there are some problems with this mechanism which are currently being fixed. http://jira.jboss.org/jira/browse/JBSEAM-1423 Proper use of conversations has been a thorn in my side for a while. If you notice, most Seam example apps have very little editing in them, and there is no master detail editing involved. The issue tracker was the only one with any kind of editable features, including master/detail and nested editing, but it was pulled in 2.0, possibly because it wasn't working properly. There is very little in the way of best practices for Seam, and everyone seems to be off doing their own thing and muddling together a solution. Pete, you've seen my sample bookstore app from my Jira issue (#1423), I have a couple of different ones (including something similar to the issue tracker) that I have been using to test this stuff out. I'm more than happy to donate something. The only caveat is that it uses the same kind of mechanisms as the bookstore app (RESTFul URLS, no @Begin annotations, and parameter passing) since it seems that this is the best way to develop a seam app that is well decoupled and a little more lightweight (i.e. not invoking new beans into a conversation that doesn't need them or is about to end). If you guys are interested, just let me know what I need to do with it to get it up to scratch. I think the two things seam needs right now is some indication of best practices, and some more diverse examples, and there is some overlap of those two issues. The documentation and examples are great for describing what you can do, but not always what you should do. There needs to be a little bit more diversity in the examples that highlight how to solve the problems people face on a daily basis, or at least indicate which problems can't be solved so we know we need to design around those issues (i.e. master/detail editing with nested conversations). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4081397#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...