You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by a clem <a....@gmail.com> on 2008/04/01 13:57:19 UTC
Re: [Orchestra] Explicit conversation starting and nested conversations
Thank's a lot for your response. What I would like to do is to be able
to share a page (ant its backing bean) between 2 conversations types,
like an activity définition can be shared between 2 process definition
in BPM. For exemple, the select customer page can be shared between
the 'send mail' and 'send invoice' use cases. I think I'm going to
hack the source to see how I can achieve this.
Regards,
On Mon, Mar 31, 2008 at 11:18 PM, simon <si...@chello.at> wrote:
> Hi,
>
>
> On Mon, 2008-03-31 at 22:36 +0200, a clem wrote:
> > Hi,
> >
> > I'm currently playing with this great framework Orchestra, trying to
> > build some small examples and a few questions came to my mind:
> > Is it possible to start a new conversation explicitly
> > (programitically). I've looked to the API but there doesn't seem to be
> > something like a begin or start method in it?
>
> Well, there are two answers to this :-)
>
> (1)
>
> If you configure a bean A in Spring to inject some other bean B that is
> configured in a conversation scope, then what is actually injected is a
> proxy. The bean B isn't actually created, and the conversation is not
> created to hold it (though the conversation might already exist if there
> are multiple beans in the same conversation).
>
> Then if A invokes any method on B, that triggers the creation of an
> actual instance of B plus the conversation to hold it (if the
> conversation does not yet exist).
>
> So I guess you could call that "programmatic" creation of a
> conversation; whether B is in the conversation or not is controlled by
> what A does.
>
> (2)
> But if you mean actually creating a Conversation object then placing
> objects in it, then no I don't think that is currently possible (or at
> least not easy).
>
> In theory there is no reason why Orchestra couldn't support that, I just
> think we didn't consider it useful. If there is a good use case then I'm
> sure that could be added.
>
> The principle is simple: create a Conversation object then get a
> reference to the current ConversationContext and add it. But the problem
> is that there are a bunch of settings that a conversation can have which
> are defined by a ConversationFactory (which is a mandatory parameter to
> the Conversation constructor at the moment). This factory is really
> expected to be a Spring scope manager object or similar; I don't know if
> it is possible to look this up nicely, or whether it is actually needed
> for manually-created conversations. But the settings would need to be
> defined somewhere.
>
> Method ConversationManager.getConversation(name) will return
> conversations by name, but returns null if the conversation does not
> exist; I don't think there is a way of forcing it to exist.
>
> Note that a bean which is *already* in a conversation can add extra
> objects to its own conversation via Conversation.setAttribute.
>
>
> > Can the same backing bean belong to more that one conversation type?
> > In other world can I share a view between multiples conversations? It
> > seem's that backing beans can only have one conversation name.
>
> No, a bean is expected to be in only one conversation. I think things
> would get quite confusing otherwise. For a start, if persistence is
> being used with conversations, then a bean could have two persistence
> contexts associated with it simultaneously which would be tricky :-)
>
> A bean in one conversation can quite happily call a bean in another
> conversation of course (orchestra conversations are not like WebFlow or
> Seam conversations).
>
> What would the use case be for this?
>
>
> > And
> > finally, is it possible to have nested conversation contexts? Thank's
> > for all your coming responses! :)
>
> No, but that feature is definitely on the to-do list.
>
> Orchestra does support multiple concurrent named conversations, as I'm
> sure you're aware. That solves many of the use-cases for nested
> conversations but not all of them.
>
> Good questions - I should put these on the Orchestra wiki FAQ page.
> Unless perhaps you would be willing to do that?
>
> Regards,
> Simon
>
>
>
Re: [Orchestra] Explicit conversation starting and nested conversations
Posted by a clem <a....@gmail.com>.
On Tue, Apr 1, 2008 at 3:00 PM, Bernhard Huemer
<be...@gmail.com> wrote:
> Hello,
>
> although Orchestra is not about pages, it's most likely that the user
> moves through two different page flows if he has started two different
> conversations (I'm not talking about two different instances of the same
> conversation but rather about two different definitions for a
> conversation!). However, there are certain cases where one page flow
> overlaps another one but Orchestra doesn't support reusing these pages
> as they would use a different conversation.
>
> The problem is that while it's true that you can use different instances
> of the same class in different conversations, it's not that easy as each
> instance has to have a different name (as you want it to be in a
> different conversation). Changing the name, however, "forces" you to
> copy the pages using this bean in order to adjust the ValueExpressions.
Exactly!! it is what I'm trying to avoid. Maybe this could be achieve
with implicit conversation names (not declaring a conversation name to
a bean) and the use of the separateConversationContext tag?
>
> Maybe I've got something wrong though ..
>
> Regards,
> Bernhard
>
> On 04/01/2008 +0200,
>
>
> "simon.kitching@chello.at" <si...@chello.at> wrote:
> > a clem schrieb:
> >> Thank's a lot for your response. What I would like to do is to be able
> >> to share a page (ant its backing bean) between 2 conversations types,
> >> like an activity définition can be shared between 2 process definition
> >> in BPM. For exemple, the select customer page can be shared between
> >> the 'send mail' and 'send invoice' use cases. I think I'm going to
> >> hack the source to see how I can achieve this.
> >>
> >> Regards,
> >>
> >> On Mon, Mar 31, 2008 at 11:18 PM, simon <si...@chello.at> wrote:
> >>
> >>> Hi,
> >>>
> >>>
> >>> On Mon, 2008-03-31 at 22:36 +0200, a clem wrote:
> >>> > Hi,
> >>> >
> >>> > I'm currently playing with this great framework Orchestra, trying to
> >>> > build some small examples and a few questions came to my mind:
> >>> > Is it possible to start a new conversation explicitly
> >>> > (programitically). I've looked to the API but there doesn't seem to be
> >>> > something like a begin or start method in it?
> >>>
> >>> Well, there are two answers to this :-)
> >>>
> >>> (1)
> >>>
> >>> If you configure a bean A in Spring to inject some other bean B that is
> >>> configured in a conversation scope, then what is actually injected is a
> >>> proxy. The bean B isn't actually created, and the conversation is not
> >>> created to hold it (though the conversation might already exist if there
> >>> are multiple beans in the same conversation).
> >>>
> >>> Then if A invokes any method on B, that triggers the creation of an
> >>> actual instance of B plus the conversation to hold it (if the
> >>> conversation does not yet exist).
> >>>
> >>> So I guess you could call that "programmatic" creation of a
> >>> conversation; whether B is in the conversation or not is controlled by
> >>> what A does.
> >>>
> >>> (2)
> >>> But if you mean actually creating a Conversation object then placing
> >>> objects in it, then no I don't think that is currently possible (or at
> >>> least not easy).
> >>>
> >>> In theory there is no reason why Orchestra couldn't support that, I just
> >>> think we didn't consider it useful. If there is a good use case then I'm
> >>> sure that could be added.
> >>>
> >>> The principle is simple: create a Conversation object then get a
> >>> reference to the current ConversationContext and add it. But the problem
> >>> is that there are a bunch of settings that a conversation can have which
> >>> are defined by a ConversationFactory (which is a mandatory parameter to
> >>> the Conversation constructor at the moment). This factory is really
> >>> expected to be a Spring scope manager object or similar; I don't know if
> >>> it is possible to look this up nicely, or whether it is actually needed
> >>> for manually-created conversations. But the settings would need to be
> >>> defined somewhere.
> >>>
> >>> Method ConversationManager.getConversation(name) will return
> >>> conversations by name, but returns null if the conversation does not
> >>> exist; I don't think there is a way of forcing it to exist.
> >>>
> >>> Note that a bean which is *already* in a conversation can add extra
> >>> objects to its own conversation via Conversation.setAttribute.
> >>>
> >>>
> >>> > Can the same backing bean belong to more that one conversation type?
> >>> > In other world can I share a view between multiples conversations? It
> >>> > seem's that backing beans can only have one conversation name.
> >>>
> >>> No, a bean is expected to be in only one conversation. I think things
> >>> would get quite confusing otherwise. For a start, if persistence is
> >>> being used with conversations, then a bean could have two persistence
> >>> contexts associated with it simultaneously which would be tricky :-)
> >>>
> >>> A bean in one conversation can quite happily call a bean in another
> >>> conversation of course (orchestra conversations are not like WebFlow or
> >>> Seam conversations).
> >>>
> >>> What would the use case be for this?
> >>>
> >>>
> >>> > And
> >>> > finally, is it possible to have nested conversation contexts? Thank's
> >>> > for all your coming responses! :)
> >>>
> >>> No, but that feature is definitely on the to-do list.
> >>>
> >>> Orchestra does support multiple concurrent named conversations, as I'm
> >>> sure you're aware. That solves many of the use-cases for nested
> >>> conversations but not all of them.
> >>>
> >>> Good questions - I should put these on the Orchestra wiki FAQ page.
> >>> Unless perhaps you would be willing to do that?
> >>>
> >>> Regards,
> >>> Simon
> >>>
> > You can have two instances of the same bean class in two different
> > conversations without problems.
> >
> > But to have the *same* instance in two different conversations still
> > doesn't make sense to me. Your example of "pages" doesn't clarify this
> > for me; orchestra is not about "pages", but about beans (some of which
> > may be backing beans).
> >
> > Regards, Simon
> >
> >
>
>
Re: [Orchestra] Explicit conversation starting and nested conversations
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> I don't know if I understood very
> well, but I'm going to fix Shale to store data in the current
> conversationContext. So I can have same dialog in differents windows.
> Do you think I have a chance of success? ( :) )
>
Yep, sounds very good! Don't know if Shale allows this easily, though.
Probably this makes a good contribution if you made it work :-)
Ciao,
Mario (too) :-D
RE: [Orchestra] Explicit conversation starting and nested conversations
Posted by ma...@accenture.com.
Thanks a lot Mario. So, next step for me is following:
I'm using Shale Dialog Manager that store dialog data in HttpSession in
a Managed Bean with scope session. I don't know if I understood very
well, but I'm going to fix Shale to store data in the current
conversationContext. So I can have same dialog in differents windows.
Do you think I have a chance of success? ( :) )
Thanks in advance
Mario
-----Original Message-----
From: Mario Ivankovits [mailto:mario@ops.co.at]
Sent: 24 aprile 2008 15.03
To: MyFaces Discussion
Subject: Re: [Orchestra] Explicit conversation starting and nested
conversations
Hi!
> The user is inserting data for a Claim reading
> from a paper, receive a call and start to insert a new Claim in a new
> browser window (or tab). At the moment I have two browser using the
same
> HttpSession, the same function and same shared data and my application
> does not work!
>
For this, with Orchestra, you have to have an outputLink e.g. "enter new
claim" which is surrounded by o:separateConversationContext.
This link must have a target="" (or any other trick) to open a new
browser window.
In this separate window then Orchestra will start a new
conversationContext where you can have the exact same conversations
running but with a different set of data.
With Orchestra the scopes look like something like this:
application->session->conversationContext->conversations
Even if the conversation name is "enterClain", this conversation is
separated between the conversationContexts.
separateConversationContext does nothing else then stripping the
conversationContext URL parameter from the URL, forcing Orchestra to
start a new context.
Ciao,
Mario
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
Re: [Orchestra] Explicit conversation starting and nested conversations
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> The user is inserting data for a Claim reading
> from a paper, receive a call and start to insert a new Claim in a new
> browser window (or tab). At the moment I have two browser using the same
> HttpSession, the same function and same shared data and my application
> does not work!
>
For this, with Orchestra, you have to have an outputLink e.g. "enter new
claim" which is surrounded by o:separateConversationContext.
This link must have a target="" (or any other trick) to open a new
browser window.
In this separate window then Orchestra will start a new
conversationContext where you can have the exact same conversations
running but with a different set of data.
With Orchestra the scopes look like something like this:
application->session->conversationContext->conversations
Even if the conversation name is "enterClain", this conversation is
separated between the conversationContexts.
separateConversationContext does nothing else then stripping the
conversationContext URL parameter from the URL, forcing Orchestra to
start a new context.
Ciao,
Mario
RE: [Orchestra] Explicit conversation starting and nested conversations
Posted by ma...@accenture.com.
Hi, I have an application using a Managed Bean with scope HttpSession to
store informations. My customer want use IE Tabs or more browser windows
to use the same function simultaneously. For axample, suppose a Call
Centre to manage Claims. The user is inserting data for a Claim reading
from a paper, receive a call and start to insert a new Claim in a new
browser window (or tab). At the moment I have two browser using the same
HttpSession, the same function and same shared data and my application
does not work!
What I understood is that with Orchestra I can define a Managed Bean
with scope "Conversation" to store data but I need that the two windows
have two differents "Converstion ID" and, obviously, two separate
instande of the same Managed Bean used to store conversation data.
Ciao
Mario
-----Original Message-----
From: Mario Ivankovits [mailto:mario@ops.co.at]
Sent: 1 aprile 2008 21.11
To: MyFaces Discussion
Subject: Re: [Orchestra] Explicit conversation starting and nested
conversations
Hi!
> Just to be clear, what you're saying is that you can't use the same
view in
> more than one conversation at a time?
>
At the moment: yes!
As I wrote, this is something we will allow in the near future, but it
would require to have a page-flow configuration.
Hmmm .... probably the new refactored conversationContext will allow it
programmatically too, not sure yet.
Anyway, I wonder why this is such an important feature ... As I wrote, I
think most cases can work with "nested-conversation-emulation" (tm ;-) )
and that will be much better in terms of memory usage - and also lowers
the chance to work with stale objects if these conversations are bound
to a persistence context.
Can you please outline some use-cases so we can put them in
consideration about how to solve that?
Ciao,
Mario
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
Re: [Orchestra] Explicit conversation starting and nested conversations
Posted by Mario Ivankovits <ma...@ops.co.at>.
Mario Ivankovits schrieb:
>> So, for example, while in the "Relationships" tab, I may want
>> to quickly view or edit a Party. The view/edit Party view is usually in the
>> Party tab. So, essentially I'm reusing the same page in a completely
>> different flow.
>>
>>
Oh - and there is a not very well known scope (some consider it a hack).
The "viewController" scope.
This allows the bean configured that way to reuse the same scope as your
viewController is configured for - and thus use the same persistence
context.
You have to follow the viewController naming rules or use the
@ViewController annotation to make that work.
Not sure if this helps here, though. I normally use that for converter
(configured via spring instead of faces-config.xml) to allow them to use
the same persistence context to load data from the database.
Ciao,
Mario
Re: [Orchestra] Explicit conversation starting and nested conversations
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> So, for example, while in the "Relationships" tab, I may want
> to quickly view or edit a Party. The view/edit Party view is usually in the
> Party tab. So, essentially I'm reusing the same page in a completely
> different flow.
>
> Now, in reality, I may end up using two different Facelet views that include
> the same composition, so this may not be an issue, but you get the idea...
>
The question for me is if the Relationship and the Party stuff are being
processed in the same conversation.
If they are not - and I'd think to - then I'd do it that way:
conversationRel navigtes to conversationParty by passing just the
primary key of the party to this tab. The party bean then will load the
party using its own persistence context.
Both conversation should be "manual" conversations.
The pro I see, if doing so, is, that if the user switch to the party tab
later on - using the normal "tab-navigation" - the previously selected
party is still there. Sort of "smart" application, no?
Having a button "start-over" which will invalidate the conversationParty
and bring up a fresh empty party-edit screen will then easily allow to
do different things.
I admit, I don't like it to think in page-flows in an webapp. Due to the
webapp-navigation possibilities I often do not see it as a single flow,
but more a "graph of flows" (better description?), Orchestras named
conversations honor that fact not that bad I think.
I often use two conversations per page. One manual-non-persistent
conversation to hold the data to recreate the state and one
access-persistent conversation to deal with persistence.
The view-controller backing bean is then the access scoped object and
gets the manual scoped "state" object injected.
If the users clicks here and there and then back (not browser back ;-) )
to the page it looks as if the application is still aware about what the
user wanted to do.
But for sure, this will not fit everyones need, just my 2€ct.
Ciao,
Mario
RE: [Orchestra] Same bean in multiple conversations
Posted by "Kito D. Mann" <km...@virtua.com>.
Along the same lines, are there restrictions for having the same bean in two
different conversations? I can see how to do it programmatically, but what
happens in this scenario:
1. Reference Bean B in conversation scope (Conversation B is started)
2. Reference Bean C in conversation scope (Conversation C is started)
3. Reference Bean B during Conversation C
Will I get the original Bean B, or a new instance that's in Conversation C?
And if it's the latter case, how can tell Orchestra that this bean can be in
multiple conversations?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kito D. Mann - Author, JavaServer Faces in Action
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
phone: +1 203-653-2989
fax: +1 203-653-2988
> -----Original Message-----
> From: Kito D. Mann [mailto:kmann@virtua.com]
> Sent: Tuesday, April 01, 2008 3:31 PM
> To: 'MyFaces Discussion'
> Subject: RE: [Orchestra] Explicit conversation starting and nested
> conversations
>
> > -----Original Message-----
> > From: Mario Ivankovits [mailto:mario@ops.co.at]
> > Sent: Tuesday, April 01, 2008 3:11 PM
> > To: MyFaces Discussion
> > Subject: Re: [Orchestra] Explicit conversation starting and nested
> > conversations
> >
> > Hi!
> > > Just to be clear, what you're saying is that you can't use the same
> > view in
> > > more than one conversation at a time?
> > >
> > At the moment: yes!
> > As I wrote, this is something we will allow in the near future, but
> it
> > would require to have a page-flow configuration.
> > Hmmm .... probably the new refactored conversationContext will allow
> it
> > programmatically too, not sure yet.
> >
> > Anyway, I wonder why this is such an important feature ... As I
> wrote,
> > I
> > think most cases can work with "nested-conversation-emulation" (tm ;-
> )
> > )
> > and that will be much better in terms of memory usage - and also
> lowers
> > the chance to work with stale objects if these conversations are
> bound
> > to a persistence context.
> >
> > Can you please outline some use-cases so we can put them in
> > consideration about how to solve that?
>
> I'm considering using Orchestra for an app that has several different
> tabs,
> each with a basic flow (either add a record, or search for a record,
> then
> edit or delete from the results). What makes it complicated is that
> within a
> particular tab, I need to bring up an editor that's technically part of
> another tab. So, for example, while in the "Relationships" tab, I may
> want
> to quickly view or edit a Party. The view/edit Party view is usually in
> the
> Party tab. So, essentially I'm reusing the same page in a completely
> different flow.
>
> Now, in reality, I may end up using two different Facelet views that
> include
> the same composition, so this may not be an issue, but you get the
> idea...
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Kito D. Mann - Author, JavaServer Faces in Action
> http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
> phone: +1 203-653-2989
> fax: +1 203-653-2988
>
RE: [Orchestra] Explicit conversation starting and nested conversations
Posted by "Kito D. Mann" <km...@virtua.com>.
> -----Original Message-----
> From: Mario Ivankovits [mailto:mario@ops.co.at]
> Sent: Tuesday, April 01, 2008 3:11 PM
> To: MyFaces Discussion
> Subject: Re: [Orchestra] Explicit conversation starting and nested
> conversations
>
> Hi!
> > Just to be clear, what you're saying is that you can't use the same
> view in
> > more than one conversation at a time?
> >
> At the moment: yes!
> As I wrote, this is something we will allow in the near future, but it
> would require to have a page-flow configuration.
> Hmmm .... probably the new refactored conversationContext will allow it
> programmatically too, not sure yet.
>
> Anyway, I wonder why this is such an important feature ... As I wrote,
> I
> think most cases can work with "nested-conversation-emulation" (tm ;-)
> )
> and that will be much better in terms of memory usage - and also lowers
> the chance to work with stale objects if these conversations are bound
> to a persistence context.
>
> Can you please outline some use-cases so we can put them in
> consideration about how to solve that?
I'm considering using Orchestra for an app that has several different tabs,
each with a basic flow (either add a record, or search for a record, then
edit or delete from the results). What makes it complicated is that within a
particular tab, I need to bring up an editor that's technically part of
another tab. So, for example, while in the "Relationships" tab, I may want
to quickly view or edit a Party. The view/edit Party view is usually in the
Party tab. So, essentially I'm reusing the same page in a completely
different flow.
Now, in reality, I may end up using two different Facelet views that include
the same composition, so this may not be an issue, but you get the idea...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kito D. Mann - Author, JavaServer Faces in Action
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
phone: +1 203-653-2989
fax: +1 203-653-2988
Re: [Orchestra] Explicit conversation starting and nested conversations
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> If you're injecting conversation-scoped beans you're actually
> injecting a bean being tied to a specific conversation (i.e. you'd
> also have to copy bean definitions just referencing
> conversation-scoped beans, not only pages!).
This is how spring works, no? You always put a bean in a scope and
injection that somewhere else then. The only exception is the
"prototype" scope. But this effectively means that this
"prototype-scoped" bean shares the same lifetime of the bean it gets
injected into.
> In my opinion that's a major impact in the architecture of Orchestra
> applications!
Pretty much exclamation marks, having use-case descriptions would be
more helpful to me ;-)
I'd like to learn what makes this such a major impact that an Orchestra
application needs to be coded differently?
What beans do you put into conversation scope? I normally put just
backing beans into any Orchestra scope - and you wouldn't share backing
beans between pages, would you?
Or are you work on service objects? But then Orchestra might not fit
well indeed.
But I have an idea how this could be solved eventually.
Image such a config:
<bean name="pageA" class="my.backing.Bean" scope="conversation.access">
<property name="service">
<orchestra:elevate conversationName="pageA-service"
scope="conversation.manual" ref="serviceBean" />
</property>
</bean>
<bean name="serviceBean" class="my.service.Bean" scope="prototype" />
The trick is the conversationName here. The only "thing-to-discuss" is
that if the pageA bean dies due to no longer being accessed any new
instance of this page bean will reuse the same serviceBean instance
(given it has not yet timed-out).
I still would consider this as feature.
You can fix that by using conversation.manual on the service bean too I
think.
At a start we can support something like that just with API calls
(ConversationManager.elevate()) and then lets figure out how
orchestra:elevate could be implemented.
Volunteers?
Ciao,
Mario
Re: [Orchestra] Explicit conversation starting and nested conversations
Posted by Bernhard Huemer <be...@gmail.com>.
Hello,
In fact, I think that this problem occurs not only when you'd like to
reuse certain pages but also when you'd like to reuse certain beans. If
you're injecting conversation-scoped beans you're actually injecting a
bean being tied to a specific conversation (i.e. you'd also have to copy
bean definitions just referencing conversation-scoped beans, not only
pages!). In my opinion that's a major impact in the architecture of
Orchestra applications!
Regards,
Bernhard
On 04/01/2008 +0200,
Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
>> Just to be clear, what you're saying is that you can't use the same view in
>> more than one conversation at a time?
>>
> At the moment: yes!
> As I wrote, this is something we will allow in the near future, but it
> would require to have a page-flow configuration.
> Hmmm .... probably the new refactored conversationContext will allow it
> programmatically too, not sure yet.
>
> Anyway, I wonder why this is such an important feature ... As I wrote, I
> think most cases can work with "nested-conversation-emulation" (tm ;-) )
> and that will be much better in terms of memory usage - and also lowers
> the chance to work with stale objects if these conversations are bound
> to a persistence context.
>
> Can you please outline some use-cases so we can put them in
> consideration about how to solve that?
>
> Ciao,
> Mario
>
>
Re: [Orchestra] Explicit conversation starting and nested conversations
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> Just to be clear, what you're saying is that you can't use the same view in
> more than one conversation at a time?
>
At the moment: yes!
As I wrote, this is something we will allow in the near future, but it
would require to have a page-flow configuration.
Hmmm .... probably the new refactored conversationContext will allow it
programmatically too, not sure yet.
Anyway, I wonder why this is such an important feature ... As I wrote, I
think most cases can work with "nested-conversation-emulation" (tm ;-) )
and that will be much better in terms of memory usage - and also lowers
the chance to work with stale objects if these conversations are bound
to a persistence context.
Can you please outline some use-cases so we can put them in
consideration about how to solve that?
Ciao,
Mario
RE: [Orchestra] Explicit conversation starting and nested conversations
Posted by "Kito D. Mann" <km...@virtua.com>.
Bernhard,
Just to be clear, what you're saying is that you can't use the same view in
more than one conversation at a time?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kito D. Mann - Author, JavaServer Faces in Action
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
> -----Original Message-----
> From: Bernhard Huemer [mailto:bernhard.huemer@gmail.com]
> Sent: Tuesday, April 01, 2008 9:00 AM
> To: MyFaces Discussion
> Subject: Re: [Orchestra] Explicit conversation starting and nested
> conversations
>
> Hello,
>
> although Orchestra is not about pages, it's most likely that the user
> moves through two different page flows if he has started two different
> conversations (I'm not talking about two different instances of the
> same
> conversation but rather about two different definitions for a
> conversation!). However, there are certain cases where one page flow
> overlaps another one but Orchestra doesn't support reusing these pages
> as they would use a different conversation.
>
> The problem is that while it's true that you can use different
> instances
> of the same class in different conversations, it's not that easy as
> each
> instance has to have a different name (as you want it to be in a
> different conversation). Changing the name, however, "forces" you to
> copy the pages using this bean in order to adjust the ValueExpressions.
>
> Maybe I've got something wrong though ..
>
> Regards,
> Bernhard
>
> On 04/01/2008 +0200,
> "simon.kitching@chello.at" <si...@chello.at> wrote:
> > a clem schrieb:
> >> Thank's a lot for your response. What I would like to do is to be
> able
> >> to share a page (ant its backing bean) between 2 conversations
> types,
> >> like an activity définition can be shared between 2 process
> definition
> >> in BPM. For exemple, the select customer page can be shared between
> >> the 'send mail' and 'send invoice' use cases. I think I'm going to
> >> hack the source to see how I can achieve this.
> >>
> >> Regards,
> >>
> >> On Mon, Mar 31, 2008 at 11:18 PM, simon <si...@chello.at>
> wrote:
> >>
> >>> Hi,
> >>>
> >>>
> >>> On Mon, 2008-03-31 at 22:36 +0200, a clem wrote:
> >>> > Hi,
> >>> >
> >>> > I'm currently playing with this great framework Orchestra,
> trying to
> >>> > build some small examples and a few questions came to my mind:
> >>> > Is it possible to start a new conversation explicitly
> >>> > (programitically). I've looked to the API but there doesn't seem
> to be
> >>> > something like a begin or start method in it?
> >>>
> >>> Well, there are two answers to this :-)
> >>>
> >>> (1)
> >>>
> >>> If you configure a bean A in Spring to inject some other bean B
> that is
> >>> configured in a conversation scope, then what is actually injected
> is a
> >>> proxy. The bean B isn't actually created, and the conversation is
> not
> >>> created to hold it (though the conversation might already exist if
> there
> >>> are multiple beans in the same conversation).
> >>>
> >>> Then if A invokes any method on B, that triggers the creation of
> an
> >>> actual instance of B plus the conversation to hold it (if the
> >>> conversation does not yet exist).
> >>>
> >>> So I guess you could call that "programmatic" creation of a
> >>> conversation; whether B is in the conversation or not is
> controlled by
> >>> what A does.
> >>>
> >>> (2)
> >>> But if you mean actually creating a Conversation object then
> placing
> >>> objects in it, then no I don't think that is currently possible
> (or at
> >>> least not easy).
> >>>
> >>> In theory there is no reason why Orchestra couldn't support that,
> I just
> >>> think we didn't consider it useful. If there is a good use case
> then I'm
> >>> sure that could be added.
> >>>
> >>> The principle is simple: create a Conversation object then get a
> >>> reference to the current ConversationContext and add it. But the
> problem
> >>> is that there are a bunch of settings that a conversation can have
> which
> >>> are defined by a ConversationFactory (which is a mandatory
> parameter to
> >>> the Conversation constructor at the moment). This factory is
> really
> >>> expected to be a Spring scope manager object or similar; I don't
> know if
> >>> it is possible to look this up nicely, or whether it is actually
> needed
> >>> for manually-created conversations. But the settings would need to
> be
> >>> defined somewhere.
> >>>
> >>> Method ConversationManager.getConversation(name) will return
> >>> conversations by name, but returns null if the conversation does
> not
> >>> exist; I don't think there is a way of forcing it to exist.
> >>>
> >>> Note that a bean which is *already* in a conversation can add
> extra
> >>> objects to its own conversation via Conversation.setAttribute.
> >>>
> >>>
> >>> > Can the same backing bean belong to more that one conversation
> type?
> >>> > In other world can I share a view between multiples
> conversations? It
> >>> > seem's that backing beans can only have one conversation name.
> >>>
> >>> No, a bean is expected to be in only one conversation. I think
> things
> >>> would get quite confusing otherwise. For a start, if persistence
> is
> >>> being used with conversations, then a bean could have two
> persistence
> >>> contexts associated with it simultaneously which would be tricky
> :-)
> >>>
> >>> A bean in one conversation can quite happily call a bean in
> another
> >>> conversation of course (orchestra conversations are not like
> WebFlow or
> >>> Seam conversations).
> >>>
> >>> What would the use case be for this?
> >>>
> >>>
> >>> > And
> >>> > finally, is it possible to have nested conversation contexts?
> Thank's
> >>> > for all your coming responses! :)
> >>>
> >>> No, but that feature is definitely on the to-do list.
> >>>
> >>> Orchestra does support multiple concurrent named conversations, as
> I'm
> >>> sure you're aware. That solves many of the use-cases for nested
> >>> conversations but not all of them.
> >>>
> >>> Good questions - I should put these on the Orchestra wiki FAQ
> page.
> >>> Unless perhaps you would be willing to do that?
> >>>
> >>> Regards,
> >>> Simon
> >>>
> > You can have two instances of the same bean class in two different
> > conversations without problems.
> >
> > But to have the *same* instance in two different conversations still
> > doesn't make sense to me. Your example of "pages" doesn't clarify
> this
> > for me; orchestra is not about "pages", but about beans (some of
> which
> > may be backing beans).
> >
> > Regards, Simon
> >
> >
Re: [Orchestra] Explicit conversation starting and nested conversations
Posted by Bernhard Huemer <be...@gmail.com>.
Hello,
although Orchestra is not about pages, it's most likely that the user
moves through two different page flows if he has started two different
conversations (I'm not talking about two different instances of the same
conversation but rather about two different definitions for a
conversation!). However, there are certain cases where one page flow
overlaps another one but Orchestra doesn't support reusing these pages
as they would use a different conversation.
The problem is that while it's true that you can use different instances
of the same class in different conversations, it's not that easy as each
instance has to have a different name (as you want it to be in a
different conversation). Changing the name, however, "forces" you to
copy the pages using this bean in order to adjust the ValueExpressions.
Maybe I've got something wrong though ..
Regards,
Bernhard
On 04/01/2008 +0200,
"simon.kitching@chello.at" <si...@chello.at> wrote:
> a clem schrieb:
>> Thank's a lot for your response. What I would like to do is to be able
>> to share a page (ant its backing bean) between 2 conversations types,
>> like an activity définition can be shared between 2 process definition
>> in BPM. For exemple, the select customer page can be shared between
>> the 'send mail' and 'send invoice' use cases. I think I'm going to
>> hack the source to see how I can achieve this.
>>
>> Regards,
>>
>> On Mon, Mar 31, 2008 at 11:18 PM, simon <si...@chello.at> wrote:
>>
>>> Hi,
>>>
>>>
>>> On Mon, 2008-03-31 at 22:36 +0200, a clem wrote:
>>> > Hi,
>>> >
>>> > I'm currently playing with this great framework Orchestra, trying to
>>> > build some small examples and a few questions came to my mind:
>>> > Is it possible to start a new conversation explicitly
>>> > (programitically). I've looked to the API but there doesn't seem to be
>>> > something like a begin or start method in it?
>>>
>>> Well, there are two answers to this :-)
>>>
>>> (1)
>>>
>>> If you configure a bean A in Spring to inject some other bean B that is
>>> configured in a conversation scope, then what is actually injected is a
>>> proxy. The bean B isn't actually created, and the conversation is not
>>> created to hold it (though the conversation might already exist if there
>>> are multiple beans in the same conversation).
>>>
>>> Then if A invokes any method on B, that triggers the creation of an
>>> actual instance of B plus the conversation to hold it (if the
>>> conversation does not yet exist).
>>>
>>> So I guess you could call that "programmatic" creation of a
>>> conversation; whether B is in the conversation or not is controlled by
>>> what A does.
>>>
>>> (2)
>>> But if you mean actually creating a Conversation object then placing
>>> objects in it, then no I don't think that is currently possible (or at
>>> least not easy).
>>>
>>> In theory there is no reason why Orchestra couldn't support that, I just
>>> think we didn't consider it useful. If there is a good use case then I'm
>>> sure that could be added.
>>>
>>> The principle is simple: create a Conversation object then get a
>>> reference to the current ConversationContext and add it. But the problem
>>> is that there are a bunch of settings that a conversation can have which
>>> are defined by a ConversationFactory (which is a mandatory parameter to
>>> the Conversation constructor at the moment). This factory is really
>>> expected to be a Spring scope manager object or similar; I don't know if
>>> it is possible to look this up nicely, or whether it is actually needed
>>> for manually-created conversations. But the settings would need to be
>>> defined somewhere.
>>>
>>> Method ConversationManager.getConversation(name) will return
>>> conversations by name, but returns null if the conversation does not
>>> exist; I don't think there is a way of forcing it to exist.
>>>
>>> Note that a bean which is *already* in a conversation can add extra
>>> objects to its own conversation via Conversation.setAttribute.
>>>
>>>
>>> > Can the same backing bean belong to more that one conversation type?
>>> > In other world can I share a view between multiples conversations? It
>>> > seem's that backing beans can only have one conversation name.
>>>
>>> No, a bean is expected to be in only one conversation. I think things
>>> would get quite confusing otherwise. For a start, if persistence is
>>> being used with conversations, then a bean could have two persistence
>>> contexts associated with it simultaneously which would be tricky :-)
>>>
>>> A bean in one conversation can quite happily call a bean in another
>>> conversation of course (orchestra conversations are not like WebFlow or
>>> Seam conversations).
>>>
>>> What would the use case be for this?
>>>
>>>
>>> > And
>>> > finally, is it possible to have nested conversation contexts? Thank's
>>> > for all your coming responses! :)
>>>
>>> No, but that feature is definitely on the to-do list.
>>>
>>> Orchestra does support multiple concurrent named conversations, as I'm
>>> sure you're aware. That solves many of the use-cases for nested
>>> conversations but not all of them.
>>>
>>> Good questions - I should put these on the Orchestra wiki FAQ page.
>>> Unless perhaps you would be willing to do that?
>>>
>>> Regards,
>>> Simon
>>>
> You can have two instances of the same bean class in two different
> conversations without problems.
>
> But to have the *same* instance in two different conversations still
> doesn't make sense to me. Your example of "pages" doesn't clarify this
> for me; orchestra is not about "pages", but about beans (some of which
> may be backing beans).
>
> Regards, Simon
>
>
Re: [Orchestra] Explicit conversation starting and nested conversations
Posted by a clem <a....@gmail.com>.
On Tue, Apr 1, 2008 at 2:30 PM, simon.kitching@chello.at
<si...@chello.at> wrote:
> a clem schrieb:
>
>
> > Thank's a lot for your response. What I would like to do is to be able
> > to share a page (ant its backing bean) between 2 conversations types,
> > like an activity définition can be shared between 2 process definition
> > in BPM. For exemple, the select customer page can be shared between
> > the 'send mail' and 'send invoice' use cases. I think I'm going to
> > hack the source to see how I can achieve this.
> >
> > Regards,
> >
> > On Mon, Mar 31, 2008 at 11:18 PM, simon <si...@chello.at> wrote:
> >
> >> Hi,
> >>
> >>
> >> On Mon, 2008-03-31 at 22:36 +0200, a clem wrote:
> >> > Hi,
> >> >
> >> > I'm currently playing with this great framework Orchestra, trying to
> >> > build some small examples and a few questions came to my mind:
> >> > Is it possible to start a new conversation explicitly
> >> > (programitically). I've looked to the API but there doesn't seem to be
> >> > something like a begin or start method in it?
> >>
> >> Well, there are two answers to this :-)
> >>
> >> (1)
> >>
> >> If you configure a bean A in Spring to inject some other bean B that is
> >> configured in a conversation scope, then what is actually injected is a
> >> proxy. The bean B isn't actually created, and the conversation is not
> >> created to hold it (though the conversation might already exist if there
> >> are multiple beans in the same conversation).
> >>
> >> Then if A invokes any method on B, that triggers the creation of an
> >> actual instance of B plus the conversation to hold it (if the
> >> conversation does not yet exist).
> >>
> >> So I guess you could call that "programmatic" creation of a
> >> conversation; whether B is in the conversation or not is controlled by
> >> what A does.
> >>
> >> (2)
> >> But if you mean actually creating a Conversation object then placing
> >> objects in it, then no I don't think that is currently possible (or at
> >> least not easy).
> >>
> >> In theory there is no reason why Orchestra couldn't support that, I just
> >> think we didn't consider it useful. If there is a good use case then I'm
> >> sure that could be added.
> >>
> >> The principle is simple: create a Conversation object then get a
> >> reference to the current ConversationContext and add it. But the problem
> >> is that there are a bunch of settings that a conversation can have which
> >> are defined by a ConversationFactory (which is a mandatory parameter to
> >> the Conversation constructor at the moment). This factory is really
> >> expected to be a Spring scope manager object or similar; I don't know if
> >> it is possible to look this up nicely, or whether it is actually needed
> >> for manually-created conversations. But the settings would need to be
> >> defined somewhere.
> >>
> >> Method ConversationManager.getConversation(name) will return
> >> conversations by name, but returns null if the conversation does not
> >> exist; I don't think there is a way of forcing it to exist.
> >>
> >> Note that a bean which is *already* in a conversation can add extra
> >> objects to its own conversation via Conversation.setAttribute.
> >>
> >>
> >> > Can the same backing bean belong to more that one conversation type?
> >> > In other world can I share a view between multiples conversations? It
> >> > seem's that backing beans can only have one conversation name.
> >>
> >> No, a bean is expected to be in only one conversation. I think things
> >> would get quite confusing otherwise. For a start, if persistence is
> >> being used with conversations, then a bean could have two persistence
> >> contexts associated with it simultaneously which would be tricky :-)
> >>
> >> A bean in one conversation can quite happily call a bean in another
> >> conversation of course (orchestra conversations are not like WebFlow or
> >> Seam conversations).
> >>
> >> What would the use case be for this?
> >>
> >>
> >> > And
> >> > finally, is it possible to have nested conversation contexts? Thank's
> >> > for all your coming responses! :)
> >>
> >> No, but that feature is definitely on the to-do list.
> >>
> >> Orchestra does support multiple concurrent named conversations, as I'm
> >> sure you're aware. That solves many of the use-cases for nested
> >> conversations but not all of them.
> >>
> >> Good questions - I should put these on the Orchestra wiki FAQ page.
> >> Unless perhaps you would be willing to do that?
> >>
> >> Regards,
> >> Simon
> >>
> You can have two instances of the same bean class in two different
> conversations without problems.
>
Yes It is what I want to do. How can I do that since beans can only
have on conversation name?
> But to have the *same* instance in two different conversations still
> doesn't make sense to me. Your example of "pages" doesn't clarify this
> for me; orchestra is not about "pages", but about beans (some of which
> may be backing beans).
>
Yes to me either! ;) I'm talking about pages because pages access
(backing) beans trough their names an having differents conversation
names means having to duplicate the page.
regards
> Regards, Simon
>
>
Re: [Orchestra] Explicit conversation starting and nested conversations
Posted by "simon.kitching@chello.at" <si...@chello.at>.
a clem schrieb:
> Thank's a lot for your response. What I would like to do is to be able
> to share a page (ant its backing bean) between 2 conversations types,
> like an activity définition can be shared between 2 process definition
> in BPM. For exemple, the select customer page can be shared between
> the 'send mail' and 'send invoice' use cases. I think I'm going to
> hack the source to see how I can achieve this.
>
> Regards,
>
> On Mon, Mar 31, 2008 at 11:18 PM, simon <si...@chello.at> wrote:
>
>> Hi,
>>
>>
>> On Mon, 2008-03-31 at 22:36 +0200, a clem wrote:
>> > Hi,
>> >
>> > I'm currently playing with this great framework Orchestra, trying to
>> > build some small examples and a few questions came to my mind:
>> > Is it possible to start a new conversation explicitly
>> > (programitically). I've looked to the API but there doesn't seem to be
>> > something like a begin or start method in it?
>>
>> Well, there are two answers to this :-)
>>
>> (1)
>>
>> If you configure a bean A in Spring to inject some other bean B that is
>> configured in a conversation scope, then what is actually injected is a
>> proxy. The bean B isn't actually created, and the conversation is not
>> created to hold it (though the conversation might already exist if there
>> are multiple beans in the same conversation).
>>
>> Then if A invokes any method on B, that triggers the creation of an
>> actual instance of B plus the conversation to hold it (if the
>> conversation does not yet exist).
>>
>> So I guess you could call that "programmatic" creation of a
>> conversation; whether B is in the conversation or not is controlled by
>> what A does.
>>
>> (2)
>> But if you mean actually creating a Conversation object then placing
>> objects in it, then no I don't think that is currently possible (or at
>> least not easy).
>>
>> In theory there is no reason why Orchestra couldn't support that, I just
>> think we didn't consider it useful. If there is a good use case then I'm
>> sure that could be added.
>>
>> The principle is simple: create a Conversation object then get a
>> reference to the current ConversationContext and add it. But the problem
>> is that there are a bunch of settings that a conversation can have which
>> are defined by a ConversationFactory (which is a mandatory parameter to
>> the Conversation constructor at the moment). This factory is really
>> expected to be a Spring scope manager object or similar; I don't know if
>> it is possible to look this up nicely, or whether it is actually needed
>> for manually-created conversations. But the settings would need to be
>> defined somewhere.
>>
>> Method ConversationManager.getConversation(name) will return
>> conversations by name, but returns null if the conversation does not
>> exist; I don't think there is a way of forcing it to exist.
>>
>> Note that a bean which is *already* in a conversation can add extra
>> objects to its own conversation via Conversation.setAttribute.
>>
>>
>> > Can the same backing bean belong to more that one conversation type?
>> > In other world can I share a view between multiples conversations? It
>> > seem's that backing beans can only have one conversation name.
>>
>> No, a bean is expected to be in only one conversation. I think things
>> would get quite confusing otherwise. For a start, if persistence is
>> being used with conversations, then a bean could have two persistence
>> contexts associated with it simultaneously which would be tricky :-)
>>
>> A bean in one conversation can quite happily call a bean in another
>> conversation of course (orchestra conversations are not like WebFlow or
>> Seam conversations).
>>
>> What would the use case be for this?
>>
>>
>> > And
>> > finally, is it possible to have nested conversation contexts? Thank's
>> > for all your coming responses! :)
>>
>> No, but that feature is definitely on the to-do list.
>>
>> Orchestra does support multiple concurrent named conversations, as I'm
>> sure you're aware. That solves many of the use-cases for nested
>> conversations but not all of them.
>>
>> Good questions - I should put these on the Orchestra wiki FAQ page.
>> Unless perhaps you would be willing to do that?
>>
>> Regards,
>> Simon
>>
You can have two instances of the same bean class in two different
conversations without problems.
But to have the *same* instance in two different conversations still
doesn't make sense to me. Your example of "pages" doesn't clarify this
for me; orchestra is not about "pages", but about beans (some of which
may be backing beans).
Regards, Simon
Re: [Orchestra] Explicit conversation starting and nested conversations
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> Use of tag separateConversationContext allows to start a new
> conversation but it isn't really a nested conversation context, since
> it has to be done in a new browser window (no context stack). Am I
> right?
>
Exactly!
This is something we might implement in the (near?) future. This will
also require you to define a page-flow in some way then - hopefully in a
VERY easy - JSF like - way. Being able to maintain a conversation
context stack is the first step in this direction I think.
I think we can post a draft for discussion on what we think how to solve
that with orchestra next week - watch out (or better, join) the dev list
(if not done already).
Ciao,
Mario
Re: [Orchestra] Explicit conversation starting and nested conversations
Posted by a clem <a....@gmail.com>.
On Tue, Apr 1, 2008 at 3:06 PM, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
>
> > Thank's a lot for your response. What I would like to do is to be able
> > to share a page (ant its backing bean) between 2 conversations types,
> > like an activity définition can be shared between 2 process definition
> > in BPM. For exemple, the select customer page can be shared between
> > the 'send mail' and 'send invoice' use cases. I think I'm going to
> > hack the source to see how I can achieve this.
> >
> I see the use case of allowing to share the page-flow between different
> conversations. And probably something like this will come in Orchestra too.
> Though, exactly the use-case of "select/search customer" I'd solve in a
> different way.
>
> Why not have - lets say conversationA which then call the search
> customer page somehow which uses conversationSearch - at the end of
> conversationSearch you'll invalidate this conversation and pass back the
> primary key of the selected customer to conversationA.
> That way the conversationSearch data can be cleaned up as soon as the
> search has been finished. No need to clutter the persistence-context of
> conversationA with lots of entities fetched by conversationSearch.
>
Yes, good idea, this is a way to implement nested conversation
contexts. But this will only work because conversationA and
conversationSearch don't share any bean definitions. To achieve the
most general case, I think we need to have explicit conversation
starting, combining with implicit conversation names, which allow to
access the same bean definition using the same name but from two
different conversation contexts.
Use of tag separateConversationContext allows to start a new
conversation but it isn't really a nested conversation context, since
it has to be done in a new browser window (no context stack). Am I
right?
regards
> Ciao,
> Mario
>
>
Re: [Orchestra] Explicit conversation starting and nested conversations
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> Thank's a lot for your response. What I would like to do is to be able
> to share a page (ant its backing bean) between 2 conversations types,
> like an activity définition can be shared between 2 process definition
> in BPM. For exemple, the select customer page can be shared between
> the 'send mail' and 'send invoice' use cases. I think I'm going to
> hack the source to see how I can achieve this.
>
I see the use case of allowing to share the page-flow between different
conversations. And probably something like this will come in Orchestra too.
Though, exactly the use-case of "select/search customer" I'd solve in a
different way.
Why not have - lets say conversationA which then call the search
customer page somehow which uses conversationSearch - at the end of
conversationSearch you'll invalidate this conversation and pass back the
primary key of the selected customer to conversationA.
That way the conversationSearch data can be cleaned up as soon as the
search has been finished. No need to clutter the persistence-context of
conversationA with lots of entities fetched by conversationSearch.
Ciao,
Mario