Thanks. I did figure out some of these approaches, but was wondering if I was missing something as none of them match the example! Of course, the proposed solutions that involve sharing the conversation between master and detail or invalidating the master from the detail mean that calling refreshMaster (as in the example) is pointless as it will have to redo that anyway when rebuilding the conversation. It just made me wonder under what conditions (conversation-wise) the example actually works, because I could not figure one out that handled both "save" and "cancel" properly!
I did come up with one more solution that might be considered a bit dangerous. When the master view needs its object list, it goes to the detail view to get it (detail in its own flash conversation). This way there is only one entity manager involved (the detail view version), but the master and detail conversations are always both running (the detail just comes and goes more often). The danger is you have to make sure you never actually do anything transactional in the master with the objects using the BO in the master view conversation as the objects "belong" to the entity manager in the detail. Thanks again for your input. At least I know I'm on the right track. Rick Mario Ivankovits wrote: > > Hi! >> I am trying to create a master-detail screen scenario and am following >> the >> best-practices guide in the wiki (the simple CRUD cycle - >> http://wiki.apache.org/myfaces/A_simple_Crud_Cycle) and it does not >> actually >> work. Am I doing something wrong? > Unhappily the author of this page did not say which scope to use for the > master and detail view. > @Werner, can you comment on it please. > >> When I do a save on the DetailView, if I call refreshList on the >> MasterView >> after saving using the DetailView "instance" of the BO, the list does NOT >> contain my changes. I understand why this is happening. The BO in the >> MasterView has its own entity manager as it is in a different >> conversation >> than the DetailView. It does not help to do >> Conversation.getCurrentInstance().invalidate() in the DetailView before >> doing a list refresh on the master view as there is still nothing to >> force >> the entity manager in the MasterView to dump its cached objects. >> > Yep, this invalidate will just invalidate the "detail" conversation, not > the one of the Master. > > Some possible ways are: > 1) If Master and Detail are both in two different conversations (flash) > simply avoid referencing the Master from your Detail. When navigating to > the Detail this will end the Master conversation automatically, on > navigating back the Master will be a fresh instance with a fresh > EntityManager ... thus, should load the data again. > > 2) End the Master conversation from within the Detail bean (not > recommended) ConversationUtils.invalidateIfExists("name of master > conversation"). > Name of "name of master conversation" is the one you configured using > orchestra:conversationName on the bean definition or the bean-name if > you didn't use that configuration. > > 3) Use the same conversation for the Master and Detail. Do this by using > the orchestra:conversationName="editXYZData" on both bean definitions. > Then they use the same EntityManager and you are fine anyway. Putting > both in the flash scope will handle the cleanup once the user navigates > away. > This is the way I'll mostly use. > > As a side note, if the Master page allows to define some filter, I often > put them into their own bean in a separate conversation of type "manual". > That way, even if the flash conversation ends the user input won't be > lost. For sure, this filter bean should not hold any entity as you might > run into problems if passing entities from one conversation to another > one. > > Hope this helps! > > > Ciao, > Mario > > > -- View this message in context: http://www.nabble.com/-orchestra--Conversation-issues-with-master-detail-tf4894353.html#a14030765 Sent from the My Faces - Dev mailing list archive at Nabble.com.
