Mario Ivankovits schrieb: > >> 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. >> > > You can create your own flow implementation on top of orchestra and use a > special conversation scope implementation which uses the conversation name > "_main" as a fixed string. Then, the only thing you have to deal with is the > conversationContext. > If your custom scope avoids creating the conversation if it doesn't exist you > even can try to implement the @Create stuff. > > I think in Orchestra everything is there to help you developing your ideas > without rewriting the core of Orchestra. >
I would second Mario's suggestion. AIUI, your suggestion effectively introduces a "default" conversation, and beans can be declared as being in the "default" conversation. The default conversation for a specific conversationContext gets changed via API calls. And something sets up the persistence-context for the default conversation as soon as the request starts rather than waiting for a method-call to a specific bean. That sounds like something that could be implemented now, without changing Orchestra much or at all, just by having a conversation with a magic name like "_main". If something is missing in the Orchestra API to allow this then we can talk about adding it in to make your approach possible. But Orchestra does work right now, for some real-world projects. So it would seem reasonable to test the new idea rather than ripping everything up first if we can. Having a conversation (and associated persistence context) set up as soon as the request starts (rather than only setting it up while a method on a conversation-scoped bean is running) would be nice. But there are a lot of potential issues with this too, like: (1) we often mix access to beans in different conversations (ie with different lifetimes) on the same page. One common example is a page displaying a persistent bean, a search-criteria and a results list. AIUI your suggestion introduces a "default" conversation for the request, but these different things might be in the "default" conversation in some views, and not in others. (2) As mario mentioned, ensuring endConversation is called appropiately is basically impossible. WebFlow might be able to arrange it because it insists that the webapp documents every valid navigation transition and so can detect navigations that are not in its list. But orchestra doesn't want to go down that road. I don't mean that the WebFlow approach is wrong, just that Orchestra currently has a low-configuration JSF-ish approach and that has its benefits too. (3) If something calls startConversation, then how does it get access to the stuff that was in the previous "default conversation"? Regards, Simon
