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 componen!
t 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#4085318
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085318
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
