to all the Seam committers and experts here on this forum: I have a feature request for Seam which I think would be very useful. It isn't any idea conceived by me. Rather, it's a feature whose value has been proven already by Spring Webflow. I'm not sure whether there is sufficient interest among the Seam user community and what the Seam leaders think about it. One problem is that unfortunately Gavin King appears to be no longer present on this forum (yes, I understand that he's probably awfully busy and cannot answer mundane support questions here). But without his support and his implementation, the feature won't probably find its way into Seam. As I don't know whether there is interest, I just provide a short description for now. And please excuse my English: Nested conversations could be a powerful mechanism to enable the definition of complex flows composed of one or more subflows. However, they are somewhat limited if there is no communication at all between the parent conversation (the calling flow) and the nested conversation (the subflow). With Seam it is easily possible to transfer state from a parent conversation to a nested conversation. It is much more difficult however to transfer state (which represents an ending result) back to the parent conversation when the nested conversation ends. For example, when specifying navigation rules in pages.xml, we can use <begin-conversation nested="true"/> to start a new nested conversation and <pages:out name="contextVar" value="#{ELexpr}"/> to initialize a context variable in the scope of the new nested conversation, where #{ELexpr} could freely reference context variables from the parent conversation scope. But transferring an ending result back to the parent conversation, when the nested conversation has ended, is difficult. There is unfortunately no elegant way to do this with Seam. As long as the nested conversation lasts, context variables of the outer conversation can only be read but not written to. And the following approach is not viable either: We cannot simply access a component from the parent conversation and call a property Setter of this component with the ending result of the nested conversation supplied as argument for this Setter. The reason is that when a component from the parent conversation is called while the nested conversation is still in progress, the ManagedEntityIdentityInterceptor saves wrappers for the called component in the scope of the nested conversation (!) and not the scope of the parent conversation. So once the nested conversation scope gets destroyed at the end of the nested conversation, the saved wrappers for the component from the parent conversation get destroyed as well. Of course, with some ugly hacks it is possible to transfer state at the end of the nested conversation back to the parent conversation. But what would be useful is an elegant solution, not an ugly hack. Spring Web flow supports the concept of an "attribute-mapper". The attribute-mapper plays a significant role when calling subflows, providing the integration between a parent flow and a child flow. In Spring Webflow any information the parent flow needs to pass into the subflow, or the subflow needs to return back to the parent, must be explicitly mapped. | Spring Webflow example: | | <subflow-state id="enterShippingInformation" flow="shipping-flow"> | <attribute-mapper> | <input-mapping name="purchase.requiresShipping" as="requiresShipping"/> | <output-mapping name="shipping" as="purchase.shipping"/> | </attribute-mapper> | <transition on="end" to="placeOrder"/> | </subflow-state> | | | // The <input-mapping> element instructs Spring Web Flow to map | // the value of the requiresShipping property of the purchase object in the | // parent flow scope to an attribute in the subflow scope with the name | // requiresShipping. The <output-mapping> element instructs Spring Web | // Flow to map the result of the shipping subflow | For Seam, we don't need an <input-mapping> for the direction from the parent conversation to the nested conversation. As mentioned above, we can easily transfer state in this direction. But an <output-mapping> would be highly desirable. It could be a simplified output-mapper to avoid problems with the ManagedEntityIdentityInterceptor. Much better than nothing at all. For example something like this | // pages.xml | | <end-conversation before-redirect="true"> | <output-mapping from="shipping" to="subFlowResult"/> | // the output-mapping instructs Seam at the end of the | // nested conversation to map the value of context variable | // named "shipping" in the scope of the nested conversation | // to a context var named "subFlowResult" in the parent | // conversation. For the sake of simplicity, | // we just map simple context variables, not EL path expressions. | | <output-mapping from="..." to="..."/> | // another output mapping | | <action execute="#{bean.method}"/> | // an action which gets executed in the scope of the parent | // conversation after the nested conversation has | // ended and before the redirect is done. | // It could serve to process the outjections to the parent conversation. | </end-conversation> | | I'm puzzled by the fact that Seam offers nothing yet in this regard. A feature like that would be highly useful when modeling complex flows and composing them of one or more subflows. I hope that an output-mapper gets added to Seam, in order to avoid having to resort to ugly hacks such as writing from the nested conversation to the parent conversation scope. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085318#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...