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.
