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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
