[orchestra] Conversation issues with master-detail

[rkull <ri...@gmail.com>]

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?  Here is what I have:

MasterView has a BO which it uses to fetch a list of all target objects
(just like in the example).

DetailView is in its own detail related flash conversation (as mentioned in
the bottom of the example), and has a reference to the BO as well. 
(manual/flash makes no difference whatsoever)

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.

The example is quite unclear on many details and was wondering if I am doing
something wrong here.  I have found several ways to make it work as
expected, but they are NOT like the example, and are a bit more difficult to
figure out as to what is going on without documentation.

My test is extremely simple and is NOT working as advertised!

Can anyone help?

-- 
View this message in context: http://www.nabble.com/-orchestra--Conversation-issues-with-master-detail-tf4894353.html#a14017094
Sent from the My Faces - Dev mailing list archive at Nabble.com.

Re: [orchestra] Conversation issues with master-detail

[rkull <ri...@gmail.com>]

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.

Re: [orchestra] Conversation issues with master-detail

[Mario Ivankovits <ma...@ops.co.at>]

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