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
