RE: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hi! The problem is, that it is hard to ensure having a stopConversation for each startConversation, and what about reloading the page where possibly the startConversation gets called twice. Well, if I'm not completely mistaken, you also have to invalidate all Orchestra conversations manually by now. Well, for conversation.access this is no problem, they die with any request not accessing any bean in the conversation. For manual-scoped conversations, this is true. However due to the map based approach, the impact of not having a converation closed is much less, and if the user navigates back it can resume the work automagically. Manual conversations also have a timeout; when not used for a while they are garbage-collected. Will this work as well in your approach? The not used thing won't work so well, yes? I don't see the point, why forcing the user to stop the conversation manually is a problem. Normally the user wont play nicely - and a web application should not force the user to do so. But, to say the truth, we often use the conversation.access for the persistence stuff and conversation.manual for storing non-persistence state of the conversation which allows to restart easily. This gives the user a great application experience I think. Reloading the page, however, doesn't matter. Well, of course, it creates another conversation but sooner a later a timeout will invalidate the one that has been created first. But then you can not talk about nested conversations, then you too have the same flat structure as Orchestra has by today. When you talk about nested conversation you normally also mean to invalidate all child conversations once the parent timeout. This clearly can not work for your scenario. So you too have to distinguish between nested conversations and start a new conversation. Currently nested conversations are supported through Orchestra Flow ... which also requires some sort of configuration/convention for the flow demarcation. Another problem ist that not each and every page-flow is triggered by a navigation-handler event, what about get requests - e.g. from the main menu. The NavigationHandler was just supposed to be an example. However, somewhere, of course, you have to implement that logic, i.e. some callback method is needed in order to handle the conversation selection, for example, you could use a ViewController for GET Requests. But then again you do not know if you'd like to start or end a conversation without specific external configuration. You can not state this as implementation detail. Starting and ending a conversation in a reasonable and controlled way is what it is all about. Orchestra just allowes to handle it in a less hot way. Of course, it's best practice not to pass any entities between Orchestra conversations, but that's just true because each Orchestra conversation has got its own persistence context. Seperating conversations and persistence contexts allows you to use the conversation scope in a more fine-grained way (for example, I'd like to reset filter criteria of a search conversation without closing the persistence context). How many levels do you want the developer to keep in mind? If you separate the conversation from the persistence scope you also have to be aware that, once the persistence context dies all the conversation cached in a conversation bean is detached. Creating a new persistence scope and pulling in conversation beans with entites loaded using another persistence scope will not work. The only workaround is to NOT cache any entity in the conversation bean and look it up from the persistence context each and every time. Which is doable, for clustering probably needed, but hard to code. And yes, the reset filter criteria is just what is easily possible (and used) with orchestra. Simply invalidate the conversation which holds the criteria. BTW: This conversation lives in a scope which does not use any persistence context at all here. This is just a matter of scope configuration. You could count it as example 3 of things I don't like in Orchestra. I have to use a single persistence context for a certain dialog (I'm calling it dialog now so that you don't mix it up with Orchestra conversations). Now I'd like to split this dialog into seperate conversations, but I can't because I have to reuse the persistence context so I'm actually reseting some values manually. :-f This is just not true, you can use as many persistence contexts as you would like to. You just have to be aware how to pass information from one conversation to another one. That you should not pass entities between persistence contexts is a limitation of the persistence framework - and nothing which is a real problem in any application, is it? I don't know what you mean by split this dialog as no persistence framework allows you to split its session, but if you'd like to push the data to other
Re: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Mario Ivankovits schrieb: Which does not mean that I am against your ideas. The opposite is the case, if all your promises turn out to be true, and if this realy adds some value, well, why not drop the way Orchestra currently works in favor of your way. Just, I need to see it in action. I feel the same as Mario here. Your ideas are interesting, and *might* turn out great. But as the recent thread shows, we both have a number of significant questions about how this would work in various scenarios. Immediately investing a large amount of time completely rewriting Orchestra from the beginning is a brave step to take; it would be very awkward if it turned out that the new idea didn't work out so well in practice. It would seem more reasonable to add the new functionality as an extension to the existing code rather than as a rewrite. Yes, it might not be so elegant to implement but it would be less to write (you don't need to implement all the existing behaviour on top of your new ideas). And *then* if it works we can talk about refactoring to clean things up. If you do take the approach we suggest: build *on* the existing code, then you can create an svn branch of the orchestra trunk and work there. Then we can reasonably easily merge those changes into trunk if things work out (orchestra core is now fairly stable). And because the new branch is an *enhancement* only, it is no big deal to even release new orchestra versions with your enhancements - the new code won't break existing users because the old code is still the same. This allows people (including Mario and I) to try out the new functionality in our existing large complex systems to see how it works in the real world. That won't be possible if you start again from scratch unless you are *very* careful to replicate the existing functionality correctly. Of course if you really want to implement everything at once (a big rewrite) then that's up to you. If you can come up with a super new implementation that does everything the old implementation does and more then great. But that's quite a big task..incremental development would seem easier. However you choose to work, I'm happy to answer any questions you have about the existing code functionality, but am not likely to contribute code directly (at least until there is something that I can actually test). Orchestra works adequately for me in its current form... Regards, Simon
Re: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hello again, However due to the map based approach, the impact of not having a converation closed is much less, and if the user navigates back it can resume the work automagically. Of course that's a nice feature of Orchestra by now, but that's what I'd call an implementation detail, because you can provide this behaviour with a single conversation model too. Manual conversations also have a timeout; when not used for a while they are garbage-collected. Will this work as well in your approach? The not used thing won't work so well, yes? Why shouldn't it work too? I meen, what's the matter with saving the last-access-time? Of course this will work too. Reloading the page, however, doesn't matter. Well, of course, it creates another conversation but sooner a later a timeout will invalidate the one that has been created first. But then you can not talk about nested conversations, then you too have the same flat structure as Orchestra has by today. When you talk about nested conversation you normally also mean to invalidate all child conversations once the parent timeout. This clearly can not work for your scenario. Well, I think that a parent conversation can't time out if there are any child conversations. Actually I really ment to invalidate only the child conversation that has been created first. However, I don't see why this should require a flat structure. If I refresh a page, the action method will be executed again, of course. However, it doesn't know anything about the conversation that has already been created before, because there's no indication for it (the URL has changed as we're just refreshing, the state remains the same, ..). The NavigationHandler was just supposed to be an example. However, somewhere, of course, you have to implement that logic, i.e. some callback method is needed in order to handle the conversation selection, for example, you could use a ViewController for GET Requests. But then again you do not know if you'd like to start or end a conversation without specific external configuration. You can not state this as implementation detail. Starting and ending a conversation in a reasonable and controlled way is what it is all about. Orchestra just allowes to handle it in a less hot way. Again, Orchestra wouldn't provide such a NavigationHandler or ViewController implementation, because as you've already said, specific external configuration would be needed in that case. The developer who is using Orchestra would have to provide such a NavigationHandler or ViewController by himself, which is no problem as it's a rather easy task. How many levels do you want the developer to keep in mind? If you separate the conversation from the persistence scope you also have to be aware that, once the persistence context dies all the conversation cached in a conversation bean is detached. Creating a new persistence scope and pulling in conversation beans with entites loaded using another persistence scope will not work. The only workaround is to NOT cache any entity in the conversation bean and look it up from the persistence context each and every time. Which is doable, for clustering probably needed, but hard to code. That might be true for a flat conversation structure, but it isn't for a nested conversation structure. I'll give you an exemplary structure: Start Conversation #1: (+ Persistence Context) Start Conversation #2 Start Conversation #3 Stop Conversation #3 Stop Conversation #2 Stop Conversation #1 (close Entity Manager) It's perfectly fine to cache entities in a nested conversation. However, if you pass entities to a totally different conversation, then of course, you've got a problem. However, using nested conversations I'm able to use the same persistence context within conversations that I'd like to invalidate earlier. However, I think I'll just have to convince you by implementing my idea, but I'm going to use a seperate branch just as Simon suggested it. ;-) regards, Bernhard Huemer On 10/28/2008 +0100, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! The problem is, that it is hard to ensure having a stopConversation for each startConversation, and what about reloading the page where possibly the startConversation gets called twice. Well, if I'm not completely mistaken, you also have to invalidate all Orchestra conversations manually by now. Well, for conversation.access this is no problem, they die with any request not accessing any bean in the conversation. For manual-scoped conversations, this is true. However due to the map based approach, the impact of not having a converation closed is much less, and if the user navigates back it can resume the work automagically. Manual conversations also have a timeout; when not used for a while they are garbage-collected. Will this work as well in your approach? The not used thing won't work so well, yes? I don't see the point, why forcing the
Re: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hi Bernhard,
It's great to see some design discussion about Orchestra!
Bernhard Huemer schrieb:
Hi folks,
I've been using Orchestra for a few months now and in doing so I've
been questioning some major implementation decisions, to be more
specific I really want to discuss if it's really necessary to bind
beans to a certain conversation (and therefore also a certein
persistence context!). Let me give you some examples:
Example 1)
I've developed some views for a search dialog that I wanted to use in
at least two different conversations. Everything worked fine for the
first conversation. The following code listing should give you an idea
of the problem.
///
view.xhtml
h:inputText value=#{conversationBean.value} /
spring-bean-config.xml
bean id=conversationBean class=... scope=conversation.manual
orchestra:conversationName=conversationA /
\\\
Maybe some of you have realized my problem by now: The bean somehow
depends on the conversation and as the view depends on the bean I
can't use it with a different conversation (or at least I'm missing a
major feature of Orchestra). :-f
The approach we (Mario I) use in these kind of situations is to
deliberately *not* share a conversation between the calling and called
pages. We pass input parameters to the called page (your search
dialog) and it returns some values. But it doesn't use the conversation
of the caller. Of course this means that it cannot access the
persistence context of the caller; in particular it cannot perform
persistence operations within the persistence context associated with
the caller. In the case of a search type page, that means that the
search dialog just returns the *key* of the record that the user
selected and the caller must then load that object again by key. We
don't find that any major inconvenience.
I actually think this design is an advantage; when a java method calls a
method on a different class, the called code cannot mess with the
private members of the caller, and this is *good*. Equally, when a JSF
view calls another, I don't think that allowing the called view to
mess with the conversation-state of the caller is good. JSF already is
such a loose programming language that we are losing all the benefits
of a strictly-typed programming language; JSF apps can easily degenerate
into spaghetti code and I think allowing free access to
conversation-state from anywhere makes things more dangerous (though
possibly more convenient in the short term).
Mario's reply mentioned the new orchestra flow stuff that I have been
working on. However that works in the same way, just a little more
convenient: the called view(s) still run in their own environment
without access to the caller except for parameters that are explicitly
passed in. In fact, orchestra-flow isolates things even more strongly as
the called flow runs not just in a new conversation, but in a completely
different conversation-context so cannot access existing beans in other
conversation-contexts at all.
An alternative approach might be for the called view to require some
kind of helper object to be passed to it. You can do this via
f:setPropertyActionListener in the calling page. The helper object can
provide methods to do persistence operations, and they will run in
whatever conversation the helper object is in, regardless of what
conversation the called view's backing bean is in. Of course the
helper object could be the backing bean for the calling view itself.
Note that I haven't tried this; however I can't see any reason why it
wouldn't work.
Example 2)
In a different part of the same application I've created a view that
should serve for three different usecases. Basically the view doesn't
change for these usecases at all, but the logic of the backing bean
does. My first approach was to determine the specific page bean at
runtime in the action method that navigates to this view. This action
method was supposed to register the specific page bean under a common
name. So somehow it can be said that I wanted to use polymorphic beans.
///
public String action() {
Conversation conversation = getCurrentConversation();
switch (criterium) {
case CASE_A:
conversation.setAttribute(commonBean, specificBeanA);
break;
case CASE_B:
conversation.setAttribute(commonBean, specificBeanB);
break;
case CASE_C:
conversation.setAttribute(commonBean, specificBeanC);
break;
default:
throw new IllegalStateException(); // shouldn't occur anway
}
return outcome;
}
view.xhtml
h:commandButton action=#{commonBean.save} /
\\\
However, that wouldn't work for two reasons:
- Orchestra only knows how to resolve Spring beans as the bean
definition determines the conversation being used (well, Orchestra
doesn't know how to resolve anything, actually it's the
EL-/VariableResolver of Spring that does this job in this case). It's
only possible to resolve such
Re: [Orchestra] Drawbacks of Orchestra I'd like to discuss
hello, are the wiki pages [1] and [2] up-to-date? regards, gerhard [1] http://wiki.apache.org/myfaces/OrchestraDialogPageFlowDesign1 [2] http://wiki.apache.org/myfaces/OrchestraDialogPageFlowDesign2 2008/10/27 Mario Ivankovits [EMAIL PROTECTED] Hi! Example 1) I've developed some views for a search dialog that I wanted to use in at least two different conversations. Everything worked fine for the first conversation. The following code listing should give you an idea of the problem. Simon developed Orchestra Flow which might solve this problem as it creates an all new conversation context for this flow and thus can reuse the conversation setup. Simon is still working on it to make it work with our latest requirements, but it should work for many use-cases already. I am not sure if there is a detailed documentation already. Example 2) In a different part of the same application I've created a view that should serve for three different usecases. Basically the view doesn't change for these usecases at all, but the logic of the backing bean does. My first approach was to determine the specific page bean at runtime in the action method that navigates to this view. This action method was supposed to register the specific page bean under a common name. So somehow it can be said that I wanted to use polymorphic beans. You might treat it as workaround (which you don't want to hear), but the latest Orchestra provides the method convObject = ConversationUtils.bindToCurrent(object) which allows you to attach all the aspects to any bean you'd like to. Allowing to use that from within the spring configuration is on our todo list. I don't want to hear anything about certain workarounds that I could have used in these cases as I think that these usecases aren't exceptional enough to justify workarounds. It is hard to know what you treat as workaround and what we treat as by design ;-) However, the missing flow part is nearly there and already usable. Summarizing it can be stated that I'd propose you to rewrite conversation handling for the next major release and I'd be willing to contribute. Note that I don't want to drop support for these named conversations, but I think that this usecase is not the default one for conversations. I know from the past that you would like to rewrite this stuff, but I've never seen a proposal what exactly and how. Don't get me wrong, but if you'd like to make the naming-conversation-way optional you need another way how to deal with the persistence context. Orchestra IS different to Seam here and probably different to Webflow. If the naming-conversations are exceptional ... I don't know, we use it heavily, and now with Orchestra Flow the last missing bit has been developed and Orchestra fits VERY nicely within our application. Probably how we built our application is exceptional (for the good and the bad ;-) ) Well, now with Orchestra Flow it might be possible to reach what you want. If I understood that right. You'd like to have a single conversation active for the request instead for a bean. So, creating a SingleConversationScope, this scope then should hold the persistence context in the conversationContext and bind/unbind it on request start/end. Different conversations then are only possible by utilizing Orchestra Flow. How parallel running conversations should work in such a setup, I don't know yet ... Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Link [1] is obsolete; it is there only for historical purposes. Link [2] is mostly up-to-date. There have been a few changes to the code that are not reflected here, but it is 95% correct and certainly good enough for a general understanding of orchestra-flow. Regards, Simon Gerhard Petracek schrieb: hello, are the wiki pages [1] and [2] up-to-date? regards, gerhard [1] http://wiki.apache.org/myfaces/OrchestraDialogPageFlowDesign1 [2] http://wiki.apache.org/myfaces/OrchestraDialogPageFlowDesign2
Re: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hi!
Example 1)
I've developed some views for a search dialog that I wanted to use in at
least two different conversations. Everything worked fine for the first
conversation. The following code listing should give you an idea of the
problem.
However (as noted in my other email) flow won't solve this issue. In
fact it sets up even more strict isolation between caller and called
views - deliberately. The called view cannot access any
conversation-scoped data except its own - and whatever parameters it
gets explicitly passed.
I thought Bernhard is searching a way how to do solve this problem, and
Orchestra Flow clearly shows how to solve the search-flow-use-case without
having to build your own parameter passing framework.
For me it was clear that passing entities between conversations is a no-go; as
with any framework which allows multiple persistence context.
Example 2)
In a different part of the same application I've created a view that
should serve for three different usecases. Basically the view
doesn't
You might treat it as workaround (which you don't want to hear),
but the latest Orchestra provides the method
convObject = ConversationUtils.bindToCurrent(object)
which allows you to attach all the aspects to any bean you'd like to.
Allowing to use that from within the spring configuration is on our
todo list.
I'm not sure how the new Conversationutils.bindToCurrent would help
here..
In your main bean you can have this switch/case to create the bean and put it
into a specific conversation, your main bean then provides a method like
getImplementation.
In your view then you write #{mainBean.implementation.xyz}.
The SingleConversationScope class was recently deleted from Orchestra -
as discussed on the list. Partly because there did not seem to be any
use-case that it was useful for.
We can resurrect it if such a use-case is found. But I don't understand
the above description...how exactly does it solve the two issues that
Bernhard had?
From discussions in the past with Bernhard I got the feeling that he don't
like the multiple-conversations per request approach. Which forced us to
create something like the view-controller scope, however, I still see no way
around that. Having the request conversation defined by the view controller
is the best we can do I think.
Ciao,
Mario
Re: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hello,
Any new ideas that could improve Orchestra would be great.
I'm not sure at the moment exactly what this rewrite
would do; what exactly are you proposing?
Well, basically I'd refactor the ConversationContext so that it's
actually the main conversation of Orchestra. The conversation itself is
almost independent of Spring (of course, there's still an according
implementation of the Scope interface, but it will be implemented way
easier). It's possible to nest conversations, i.e. a there's a certain
hierarchy of conversations.
Each conversation has got it's own lifecycle and therefore it's possible
to register so-called conversation listeners in order to hook logic
into such lifecycle phases.
- listener.conversationStarted(ConversationEvent event);
This method will be called once a conversation starts as the name
implies. The default implementation requires the user to start
conversations explicitly, for example by calling
manager.startConversation() where manager is a ConversationManager
that you can inject into your beans (or lookup via an EL-expression).
- listener.conversationResumed(ConversationEvent event);
This method will be called once the user accesses a URL with the
according request parameter of the conversation, i.e. if the user
accesses the URL http://localhost:8080/something.jsf?conversationId=1;.
- listener.conversationSuspended(ConversationEvent event);
This method will be called once such a request as above has been processed.
- listener.conversationEnded(ConversationEvent event);
This method will be called once the user invalidates a conversation.
The following example describes the most obvious usecase:
JpaPersistenceListener
- listener.conversationStarted():
Create the persistence context and put it into the conversation.
- listener.conversationResumed():
Bind the persistence context of the conversation
- listener.conversationSuspended():
Unbind the persistence context of the conversation
- listener.conversationEnded():
Close the persistence context
No additional proxy class is needed in that case and a persistence
context is available to the whole application (you don't have to call
DAO methods through conversation-scoped beans). If you don't persistence
context support, then just don't configure the JpaPersistenceListener.
Those who know Spring Web Flow will think that I'm just proposing to do
it like Spring Web Flow does - and yeah, they're right as I think that's
the way to go. However, there's still the need for a persistence
interceptor as you're still able to use the current conversation model
of Orchestra. The difference is that such conversations will be nested
within the main conversation of Orchestra and not within a
ConversationContext.
In doing so, it's not required to specify the conversation you'd like to
use on your bean definitions, as there's just one conversation: the
current one and Orchestra is responsible for determining that one. Of
course, this approach doesn't allow you to use two different
conversations on the same view, but then you can still use the previous
conversation model of Orchestra.
The SpringSingleConversationScope (or whatever it was called like) was a
start in the right direction, but I think it's wrong to implement a
single conversation-model on a named conversation-model. I'd propose to
do it the other way around.
regards,
Bernhard Huemer
On 10/27/2008 +0100,
Simon Kitching [EMAIL PROTECTED] wrote:
Hi Bernhard,
It's great to see some design discussion about Orchestra!
Bernhard Huemer schrieb:
Hi folks,
I've been using Orchestra for a few months now and in doing so I've
been questioning some major implementation decisions, to be more
specific I really want to discuss if it's really necessary to bind
beans to a certain conversation (and therefore also a certein
persistence context!). Let me give you some examples:
Example 1)
I've developed some views for a search dialog that I wanted to use in
at least two different conversations. Everything worked fine for the
first conversation. The following code listing should give you an idea
of the problem.
///
view.xhtml
h:inputText value=#{conversationBean.value} /
spring-bean-config.xml
bean id=conversationBean class=... scope=conversation.manual
orchestra:conversationName=conversationA /
\\\
Maybe some of you have realized my problem by now: The bean somehow
depends on the conversation and as the view depends on the bean I
can't use it with a different conversation (or at least I'm missing a
major feature of Orchestra). :-f
The approach we (Mario I) use in these kind of situations is to
deliberately *not* share a conversation between the calling and called
pages. We pass input parameters to the called page (your search
dialog) and it returns some values. But it doesn't use the conversation
of the caller. Of course this means that it cannot access the
persistence context of the caller; in particular it cannot perform
RE: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hi! Well, basically I'd refactor the ConversationContext so that it's actually the main conversation of Orchestra. The conversation itself is almost independent of Spring (of course, there's still an according implementation of the Scope interface, but it will be implemented way easier). It's possible to nest conversations, i.e. a there's a certain hierarchy of conversations. The main problem I see with this approach is that you HAVE to use a flow definition, else Orchestra has no chance to determine when to end a conversation and when to reuse the current one. In a web-application, where you have global menues where the user is able to suspend the current conversation and jump right to the start of another one (or resume it) it is hard to find the conversation demarcation without a flow description. In fact I tried such thing in Orchestra BEFORE I started to go the named-conversation way. Orchestra just fits way better with this free-floating-named-conversations in our application. As far as I know Spring WebFlow is such a system and is able to deal with persistence contexts already. Each conversation has got it's own lifecycle and therefore it's possible to register so-called conversation listeners in order to hook logic into such lifecycle phases. Some of the events you outlined are already there in Orchestra. Also using Orchestra without persistence at all works great, on a per-scope-configuration basis! Still, the beauty of Orchestra is that it supports use-cases like: 1) Doing Order-Processing 2) Suspend task 1 and do some different things like, update customers master-data 3) Go back to Order-Processing and continue All this works without a single line of flow-description and by nicely separate the persistence contexts, so the memory of task 2 has been freed while task 1 is stil there. Also no user-interaction is required (pause, restart, etc) and no other sort of convention. On top of THAT we built the flow, so each flow separates even more by still keeping the easy-to-use multiple conversation feature. Where a flow is required (e.g. search-pages) you can use them now. So, it is not only using two conversations during the same render-request, no, it is about using different parallel conversations for different tasks without additional configuration on view level. In fact, if one finds a method how Orchestra can determin what is the CURRENT conversation we could get rid of the viewController-scope, but since Orchestra talks about beans and not about views in its innerst, that is hard to find. For me the single-conversation approach looks like a limitation, which to break out requires a flow-description. Sorry, at all it is hard for me to see what is better to do it like Spring WebFlow. Ciao, Mario
Re: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hello, The main problem I see with this approach is that you HAVE to use a flow definition, else Orchestra has no chance to determine when to end a conversation and when to reuse the current one. Well, no, you don't have to use a flow definition. Managing the conversation from a user's perspective is clearly defined as an according API will be provided. If the user doesn't call a method like conversation.invalidate() the conversation won't end. For example, I'm thinking of creating a configurable artifact that manages the lifecycle of a conversation - a so-called ConversationManager. The basic implementation would require the user to call the method manager.startConversation(), i.e. the user would have to configure the beans so that a ConversationManager will be injected. However, another ConversationManager could possibly know how to deal with annotations like @Create or @End. It would be even possible to configure a special ConversationManager that automatically creates a new conversation if you try to access it (i.e. just as it is now) and of course there's the possibility of using a flow definition for that purpose. In a web-application, where you have global menues where the user is able to suspend the current conversation and jump right to the start of another one (or resume it) it is hard to find the conversation demarcation without a flow description. In fact I tried such thing in Orchestra BEFORE I started to go the named-conversation way. Orchestra just fits way better with this free-floating-named-conversations in our application. Well, I'm not particularly against named conversations. I'm just saying that neither the view nor a Spring bean is responsible for determining the name of this conversation, but a special flow logic is (and I'm still not talking about flow definitions). For example, in this case I'd prefer to write a NavigationHandler for my application that knows how to deal with this usecase. Basically it uses the according API to suspend the current conversation and resume the according one. Of course, Orchestra could only do that automatically if there was something like a flow definition, but I'd prefer to expose an API so that the user is able to write such a NavigationHandler on his own. However, this approach enables you to control conversations in a more fine-grained way. For example, if you've got a master-/detail-view being surrounded by global navigation menus, you could use the exposed API so that you'll resume the conversation for the detail you've choosen previously if you select it again (of course, assuming that you only have suspended the conversation, i.e. you've clicked on a global menu entry before). Also no user-interaction is required (pause, restart, etc) and no other sort of convention. Well, of course you could say that this is a burden for the user, but it comes with great flexibility too (see my master-/detail-view example). Convenient default implementations could then reduce the complexity without limitating the user's flexibility. For me the single-conversation approach looks like a limitation, which to break out requires a flow-description. Simply said, yes that's true, but the flow description doesn't have to be an XML flow definition. What I'd like to see, is an Orchestra API that allows me to describe my flows programmatically at runtime as this is a much more powerful approach for managing conversations. regards, Bernhard On 10/27/2008 +0100, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Well, basically I'd refactor the ConversationContext so that it's actually the main conversation of Orchestra. The conversation itself is almost independent of Spring (of course, there's still an according implementation of the Scope interface, but it will be implemented way easier). It's possible to nest conversations, i.e. a there's a certain hierarchy of conversations. The main problem I see with this approach is that you HAVE to use a flow definition, else Orchestra has no chance to determine when to end a conversation and when to reuse the current one. In a web-application, where you have global menues where the user is able to suspend the current conversation and jump right to the start of another one (or resume it) it is hard to find the conversation demarcation without a flow description. In fact I tried such thing in Orchestra BEFORE I started to go the named-conversation way. Orchestra just fits way better with this free-floating-named-conversations in our application. As far as I know Spring WebFlow is such a system and is able to deal with persistence contexts already. Each conversation has got it's own lifecycle and therefore it's possible to register so-called conversation listeners in order to hook logic into such lifecycle phases. Some of the events you outlined are already there in Orchestra. Also using Orchestra without persistence at all works great, on a
