Glauco P. Gomes schrieb:
What's happening is that the conversation (from a bean in access
scope) is destroyed when I open a trinidad dialog, and when I return
form the dialog, the first bean has loosed his state.
Is this the correct behavior?
Well, it's obviously not what a user of trinidad
On Thu, Oct 9, 2008 at 9:31 AM, Simon Kitching [EMAIL PROTECTED] wrote:
Glauco P. Gomes schrieb:
What's happening is that the conversation (from a bean in access scope) is
destroyed when I open a trinidad dialog, and when I return form the dialog,
the first bean has loosed his state.
Is
Matthias Wessendorf schrieb:
On Thu, Oct 9, 2008 at 9:31 AM, Simon Kitching [EMAIL PROTECTED] wrote:
Glauco P. Gomes schrieb:
What's happening is that the conversation (from a bean in access scope) is
destroyed when I open a trinidad dialog, and when I return form the dialog,
the first
On Thu, Oct 9, 2008 at 12:55 PM, Glauco P. Gomes
[EMAIL PROTECTED] wrote:
Matthias Wessendorf escreveu:
I think I got it working, by added some special cfg for the new window,
launched by the dialog:
Matthias Wessendorf escreveu:
I think it worked w/ the mentioned extra config,
but I can't remember
I tested this now and didn't worked.
Maybe creating a maintainScopeViewIds like ignoreViewIds in
AccessScopeManagerConfiguration to not destroy access scoped beans in
specific views resolves
Simon Kitching escreveu:
Yes, it is a workaround, but not too ugly. I suggest you try again,
and this time enable debugging output for Orchestra to see what
happens. Orchestra uses commons-logging and generates a reasonably
detailed amount of output. I can't see why the suggested workaround
Simon Kitching escreveu:
Since Orchestra version 1.2, child conversation contexts can be
created in Orchestra to handle this sort of situation (pause state and
later resume). But there would need to be some way to trigger the
creation of a child conversation context when a Trinidad dialog
Matthias Wessendorf escreveu:
I think I got it working, by added some special cfg for the new window,
launched by the dialog:
http://code.google.com/p/facesgoodies/source/browse/trunk/src/main/resources/orchestra.spring.xml
my facesgoodies currently uses two types of Trinidad dialogs:
-one w/o
Glauco P. Gomes schrieb:
Simon Kitching escreveu:
Yes, it is a workaround, but not too ugly. I suggest you try again,
and this time enable debugging output for Orchestra to see what
happens. Orchestra uses commons-logging and generates a reasonably
detailed amount of output. I can't see why
Simon Kitching escreveu:
Flow works well right now for non-popup windows, ie you can call
some sequence of pages then return back to the calling point.
But some of our use-cases require us to use the sandbox s:modalDialog
or richfaces modal dialogs to display the called pages in, rather
What's happening is that the conversation (from a bean in access scope)
is destroyed when I open a trinidad dialog, and when I return form the
dialog, the first bean has loosed his state.
Is this the correct behavior?
How can I integrate the Trinidad Dialog Framework with Orchestra access
11 matches
Mail list logo
