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 conversation scoped beans you are free to do so - technically spoken. > However, actually I wanted to talk about my search-use-case as I think > that's no problem. Even with a single conversation model it's still > possible to create nested conversations (which would meet all > requirements for this use-case). If the user uses some sort of global navigation you do not know which conversation to end. This is NOT trivial to solve without flow configurations. Nested-Conversations without external flow configuration won't work, I promise. > Probably there are even further more examples where a NavigationHandler > won't work, but that actually really doesn't matter, because using an > API the user has got the possibility to adapt Orchestra to his/her > needs. (Btw. implementing another scope that fulfills ones requirements > is somehow "extending Orchestra" and not really "using Orchestra" ..). But to test out your ideas you first have to extend Orchestra, as it clearly does not fit your needs, and then we can decide making it the new best practice. Orchestra has a sandbox, no problem to start there. > I think you've answered that already on your own. If "hacking around" > is > needed for something "trivial" like that, something has to be done, at > least in my opinion. Sorry that "hacking around" triggered somehting like that. With "hacking around" I just meant developing your idea. Orchestra is using another philosophy you have in mind. There is not much to say about that. Implementing and using your "trivial" (your word ;-) ) idea is anything else than trivial I think. > Well, basically you've told me to implement my own conversation scope > and my own approach to persistence context handling, if I really feel > the need for something like that. But what remains of "the core of > Orchestra"? - the ConversationContext. Yes, and if it is really that good we can use that as new system ground for Orchestra, what is bad with that? You also do not have to go the "proxied" bean way. You simply can use a filter to setup the persistence. That is really easy. Just lookup the conversation and call bind/unbind on the persistence provider. The problem I see is that I still do not understand how your implementation will work with all the scenarios we are currently using - we can not drop these scenarios. For me, nested-conversations won't work without some sort of flow description (external or annotations does not matter) which will assure that the conversation stack is always clean and in known state. I also can not see how a single-conversation model will be able to emulate the multi-conversation model Orchestra currently uses later on then. Unfortunately I am not able to convince you about the beauty of Orchestra. But that is ok, differente people have different views and needs. Going the scope way has been discussed with others and at that time we came to the conclusio that this is a well-known pattern and easy to understand. And as I said, it works very well here and is easy to code with. BTW: I never cared how other frameworks worked as I wanted to implement the vision which has been built in my head after some discussions with other developers. That other frameworks work different does not mean that they are better, even if the framework is that company-backed (and thus more accepted) like JBoss Seam or Spring WebFlow. Clearly I can not welcome a rewrite of Orchestra as long as I do not get to the point you vision. We are at Version 1.3 and Orchestra is used, even in the wild. 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. You have to understand that this can not be demonstrated by rewriting Orchestra trunk, thus, I suggested to "hack-around" your idea into the current Orchestra API. Which you declined. Next thing I can propose is to create a branch of Orchestra and start rewriting it there. Since I do not understand all your visions you have to do the main work. Keep in mind that stuff like * Orchestra Flow - handling dialog scenarios * allowing converters/validators using persistence * allowing multiple, different configured, conversations at the same time (same request/same view) (long-living criteria-selector whith short-living criteria-result-view) * allow to jump in the application back and forth using the navigation by not creating new conversations all the time, reuse the conversation (if still living) so the user can resume the work * allow to timout other conversations if not accessed any more. (order-processing, customer-update scenario) has to work with your new design too. Also keep in mind that the current solution just requires to call "Conversation.invalidate" in some cases. So Orchestra supports the "do not clutter your code with persistence stuff" paradigm. The main idea of most ORM frameworks. Also, please keep in mind that Orchestra has to be different to the others e.g. Seam and WebFlow, else we have to stand the question why to use Orchestra ... something I will not spend my time for - to say the truth, even I would use the "orignals" then. Is this an acceptable proposal? I really would like to see it work and incorporate it into Orchestra then. If not, the last thing I see is to start another project, which surely is suboptimal; to say its best. Ciao, Mario
