New User Question

[Keith Lyall]

Hi,

I have been using Spring MVC for a while but have not used Spring Webflow yet.

I saw in the doc that there is integration between the two but I can't see anything that takes you through the steps of converting a Spring MVC webapp to include Spring Webflow.

For instance can I use my Spring MVC controllers unchanged or do I have to redevelop them to extend the FormAction class?

I am sure I read somewhere that it is recommended that Spring Webflow is used instead of using Spring MVC's AbstractWizardFormController. Is this correct or should more of a webapp be converted to Webflow?

For example if the webapp was doing standard search -> list -> view item -> edit item, would you only use Webflow for the edit parts when more than one page is required?

Thanks.

[klr8]

I suggest you read the SWF intro:

http://www.ervacon.com/products/swf/intro

That should answer most of your questions.

Erwin

[gezhall]

Some further comments on Webflow used with SpringMVC from another new user:

Like the topic poster, I was first confused about how to integrate the two. It seemed from some articles I had read that you could simply replace the app-servlet.xml elements with a webflow xml template. But of course it's not that simple. You can reuse all your form backing objects, and all your validators - webflow uses these in an indentical way to SpringMVC. But you will need to rewrite any Action classes.

It's therefore easier to start your webflow app from scratch, than to convert an existing SpringMVC app into webflow.

Once you do have your combined app up and running, it seems to me that SpringMVC isn't really doing all that much anymore. It is responsible for all the bean declarations (though that's more Spring's IoC container than MVC) and it's responsible for getting the message resources, and it delegates the 'flow' logic to Webflow. Other than that it doesn't seem to be doing an awful lot...

The article mentioned above is very good, and helped me a lot to understand what is going on. But, I would read it in conjunction with the many other good examples out there - this one seems to do some things in strange ways which led me astray.

[Keith Lyall]

Thanks everyone for the replies.

Gezhall, that was pretty much the conclusion I was coming to but I wanted to check I hadn't missed anything.

I guess with Webflow having flow and flash scopes which Spring MVC does not, there is not a straight migration between the two.

The effort so far to convert across to Action/FormAction from the MVC equivalent is minor and the SWF *-flow.xml defintions are easy to understand.

My current focus is migrating Acegi security across to SWF. This article seems to be a good solution but I am having a couple of issues as I mention in the article comments.

[Marten Deinum]

Well as the name suggests FlowSecurityInterceptor it isn't a filter and as such should be configured differently. Add a ConditionalFlowExecutionListenerLoader to your flow configuration

	<bean id="executionListenerLoader" class="org.springframework.webflow.execution.factory.ConditionalFlowExecutionListenerLoader">
	   <property name="listeners">
	      <map>
	         <entry key-ref="flowSecurityInterceptor" value="*"/>
	      </map>
	   </property>
	</bean>

This will attach the listener to all request to execute a flow,event,transition. The next thing to do is to register this FlowExecutionListenerLoader with your FlowExecutor.

	<bean id="flowExecutor" class="org.springframework.webflow.executor.FlowExecutorImpl">
		<constructor-arg ref="flowRegistry"/>
		<constructor-arg>
			<bean class="org.springframework.webflow.engine.impl.FlowExecutionImplFactory">
				<property name="executionAttributesMap" ref="executionAttributes"/>
				<property name="executionListenerLoader" ref="executionListenerLoader"/>
			</bean>
		</constructor-arg>
		<constructor-arg ref="repository"/>
	</bean>

configure the remainder as usual.

If you have anymore questions feel free to ask, I'm currently writing a demo/presentation regarding the SWF-93 JIRA issue. I'll check if I', allowed to post the presenation/demo somewhere.

[klr8]

The article mentioned above is very good, and helped me a lot to understand what is going on. But, I would read it in conjunction with the many other good examples out there - this one seems to do some things in strange ways which led me astray.

Could you be more specific? What did you find strange in the article? If it's confusing in any way I would like to improve it.

I wouldn't say you need to 'convert' your application from SpringMVC to SWF. SWF is an additional tool in your toolbox you can use to tackle the complex conversations. So SpringMVC and SWF coexist in many applications.

Erwin

[gezhall]

Could you be more specific? What did you find strange in the article? If it's confusing in any way I would like to improve it.

I wouldn't say you need to 'convert' your application from SpringMVC to SWF. SWF is an additional tool in your toolbox you can use to tackle the complex conversations. So SpringMVC and SWF coexist in many applications.

Erwin

Hi Erwin. It's probably more my lack of understanding than anything too confusing in the article - but here are the things that left me wanting a bit.

1) In your example you do not provide any custom Action classes, but simply use the default one provided by webflow. As this was one of the main things I was looking for (to convert my existing SpringMVC app) I found this slightly confusing at first - you don't really show how you would interact with your business classes, DAO etc.

2) The thing that really got me was that in your formAction xml delarations, you do not have a property for the formName. All the examples that I have seen elsewhere have this (along with the form class, and the validator), so the JSP knows how to refer to the form backing object. Your way, I simply couldn't get it to work! Until I put in the formName attribute, and it was fine.

3) There seems to be different ways of formatting the flow.xml file. Where yours starts <start-state idref="enterCriteria"/> ... other examples seem to structure it like this: <webflow id="some_id" start-state="enterCriteria">. Is there a difference, or a preference?

4) Lastly I found that using the flow.xml to really seperate the actions from the views improved readability, particularly for beginners and especially for non-technical people. Surely that is one of webflow's goals? Some examples try and pack actions into the view state, rather than seperate them into a logical flow. For example, this article (which I just noticed is also one of yours!) is a lot clearer. http://www.theserverside.com/tt/arti...=SpringWebFlow

Hope this all makes sense, and thanks for all the help you are offering!

[Marten Deinum]

1) In your example you do not provide any custom Action classes, but simply use the default one provided by webflow. As this was one of the main things I was looking for (to convert my existing SpringMVC app) I found this slightly confusing at first - you don't really show how you would interact with your business classes, DAO etc.

You don't have to write custom action classes. You could simply pass the properties to the services directly and assign the returned values to a property in a scope. No need to define a custom action.

2) The thing that really got me was that in your formAction xml delarations, you do not have a property for the formName. All the examples that I have seen elsewhere have this (along with the form class, and the validator), so the JSP knows how to refer to the form backing object. Your way, I simply couldn't get it to work! Until I put in the formName attribute, and it was fine.

You don't need to specify the formName. The default formName for FormActions is formObject, just refer to this in yuor jsp. We changed it to command so we could use our views which we had when we used SpringMVC (which we still use in parts of our application).

3) There seems to be different ways of formatting the flow.xml file. Where yours starts <start-state idref="enterCriteria"/> ... other examples seem to structure it like this: <webflow id="some_id" start-state="enterCriteria">. Is there a difference, or a preference?

Versions... <webflow was the tag used in older pre 1.0 versions of SWF. So no preference just differences in version of Spring Web Flow.

[gezhall]

You don't have to write custom action classes. You could simply pass the properties to the services directly and assign the returned values to a property in a scope. No need to define a custom action.

Are you saying that writing a custom action class is bad practice, or simply just not always necessary? Would an example of what you are suggesting be the way, in your tutorial, you pass the SearchCriteria to the Phonebook and set the 'results' object into the scope?

You don't need to specify the formName. The default formName for FormActions is formObject, just refer to this in yuor jsp. We changed it to command so we could use our views which we had when we used SpringMVC (which we still use in parts of our application).

I'm not quite getting this. When I try what you suggest, I get an exception (it doesn't recognise the 'formObject' variable in the jsp). Also, in your example, you say this: "By default the form action will store the form backing object in flow scope and will assign it a name based on the class name: "searchCriteria" in this case." - which seems to contradict what you just told me. This, strangely, is now working for me without explicit declaration of the form name - though it definitely wasn't before

Also, what if you have more than one form object? Then wouldn't you need to have identifiers for each one?



Finally, could you explain the significance of the following form decleration? Mine seem to work just fine with the normal <form method="post"> at the start.

<form:form commandName="searchCriteria" method="post">


Thanks again.

[klr8]

Are you saying that writing a custom action class is bad practice, or simply just not always necessary?

It's not a bad practice, but in most simple cases you can avoid it and have SWF directly call your service layer using a bean-action, like in the Phonebook example.

The form object name defaults like explained in the article, so: "By default the form action will store the form backing object in flow scope and will assign it a name based on the class name: "searchCriteria" in this case. ".

You can ofcourse always be explicit, for instance if you need multiple form objects of the same class.

That form:form declaration just makes things a bit more explicit.

Erwin