struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Schneider <>
Subject Re: Spring Web Flow Plugin Feeback
Date Thu, 15 Mar 2007 12:56:33 GMT
mraible wrote:
> If I should post feedback for the SWF plugin to the user list, please let me
> know.  I've been playing a bit with this plugin today.  I have a fair bit of
> experience using SWF with Spring MVC and JSF, and this is the first time
> I've tried it with Struts 2.
> Some thoughts:
> 1. Using a _flowId to indicate the flow to use.
> With Spring MVC, it's possible to configure something like the following:
>     <bean id="flowController"
> class="org.springframework.webflow.executor.mvc.FlowController">
>         <property name="flowExecutor" ref="flowExecutor"/>
>     </bean>
>     <flow:executor id="flowExecutor" registry-ref="flowRegistry"/>
>     <flow:registry id="flowRegistry">
>         <flow:location path="/WEB-INF/flow-*.xml"/>
>     </flow:registry>
> This allows you to call the url for the flowController with a _flowId
> parameter to specify the flow to use.  The default flow name is the name of
> the flow's XML file.  For example: flow.html?_flowId=flow-shoppingcart to
> load the /WEB-INF/flow-shoppingcart.xml flow.  This doesn't seem to be
> possible with this plugin.
Please take a look at FlowAction.  There is a flowId parameter that is 
injected via an interceptor.  This determines which flow is kicked off 
initially.  I usually create one FlowAction alias for each flow that I 
have.  It seemed like more of a struts2/webwork way of doing things, the 
_parameter stuff just annoyed me.  :-)
> 2. Redirecting to the controller.  I noticed in the example,
> redirect-by-default is turned off:
>     <flow:executor id="flowExecutor" registry-ref="flowRegistry">
>         <flow:execution-attributes>
>             <flow:alwaysRedirectOnPause value="false"/>
>         </flow:execution-attributes>
>     </flow:executor>
> I'm assuming this is done because redirects are handled by the results
> themselves?  With SWF, I've often called methods on beans (actions) directly
> from the flow definition rather than invoking an action based on a URL.  In
> other words, Spring MVC (and JSF) always posts to /flow.html and then
> redirects back to the same URL.  This is quite a bit different than the
> Struts 2 example that does Struts-based redirect. SWF does allow you to do
> an external redirect, but that's usually handled from w/in the flow:
> <end-state id="finish" view="externalRedirect:/users.html"/>
> Of course, to call methods on actions from the flow, you may have to
> register them as Spring beans, but that's expected.  In many cases, you can
> get away from writing controllers and just use SWF's default FormAction to
> route - then call your middle-tier classes to persist and grab data.
I expect webwork to do all redirects and didn't rely on SWF redirect 
functionality at all.  In fact, the flow action doesn't even support 
that result type so it would fail if you tried that.  The redirect stuff 
only seemed useful for JSF and Spring MVC--I didn't see a real need in 
Struts2/Webwork for it.  There quite a bit of overlap between the 2 
frameworks, in the cases where functionality was duplicated, I used the 
Struts2 functionality.
> 3. It'd be nice if there were "prefix" and "suffix" values you could set on
> the front "flowController" so you could use logical view names in the flow
> definition, rather than having to do dual-entry in the flow definition and
> struts.xml to match view names to result names.
Again, I usually handled this through FlowAction aliases with the flowId 
hardcoded as a static param in the xwork xml.  That way the only 
parameter you need to specify to the flow action is the eventId.  
(Assuming your using the session flow exec key interceptor)
> AFAIK, all of this might be possible right now - I haven't dug into the code
> too much to see
It seems like you are expecting SWF to work exactly the same as it did 
in SpringMVC/JSF and that was not my goal.  I wanted SWF to work in a 
more Struts2/Webwork-ish way--so there are differences in how you do 
things.  I like felt this would make it easier for Struts2 users since 
you can use things like the url tag, interceptors and xwork 
configuration to do most of the work.  I appreciate the feedback, at 
this point I don't think there are a ton of users and I've only received 
1 other email asking about this plugin.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message