Spring WebFlow Refcard: Meet The Author

This weeks Refcard, written by Craig Walls, covers the Spring WebFlow framework. I spoke with Craig to find out more about Spring WebFlow, it's relationship to Spring and how to get started using WebFlow.

DZone: Hi Craig, can you introduce yourself please?

Craig: I'm Craig Walls, programmer, author, and connoisseur of chips and salsa. Most people know me as the author of Spring in Action and Modular Java. And I occasionally stand in front of a room of fellow geeks and talk about things like Spring and OSGi.

DZone: Your Refcard covers Spring WebFlow, could you describe the technology?

Craig: Most websites are free-flowing, allowing visitors to click their way to almost anything that catches their eye. But sometimes the web application needs to guide the user through a defined flow. A shopping cart and checkout process on an e-commerce site is a common example. That's where Spring Web Flow comes in.

Yes, it's true that you can build a flow-driven application using any web framework. But with most web frameworks, the flow is spread out across multiple components and views and there's no one place to go to get the big picture of what the flow looks like. Imagine going on a cross-country road trip where you have to stop at every town and city along the way and ask where you should go next. That's what a flow in most web frameworks is like--each stop along the flow knows the next step in the flow.

In contrast, Spring Web Flow lets you build the flow separate from any components or views that are behind the flow. It's like drawing out a map before going on a road trip.

DZone: And how is Spring WebFlow related to Spring?

Craig: Spring Web Flow is based on Spring MVC, the general purpose web framework that's part of the core Spring distribution.

DZone: How are you involved with Spring WebFlow? Have you been using it for long?

Craig: I'm involved with Spring Web Flow primarily because I'm involved with most things that are in the Spring Portfolio. It's a sort of addiction, I suppose.

Anyhow, I've written several small Web Flow application over the past few years. More recently, I was involved in a project for a client that used Web Flow to guide call center representatives in walking customers through issue resolution. It was an especially interesting use of Spring Web Flow because, instead of using conventional JSP or JSF views, this application produced JSON views that were consumed by an Ext-JS front-end--for a richer user experience.

I'm currently neck deep in writing the third edition of Spring in Action. I have just wrapped up the Spring Security chapter and am getting started on the Spring Web Flow chapter. Suffice it to say that the topic is fresh in my mind.

DZone: What do I need to do before I can use Spring webflow?

Craig:  It kinda depends on how you are building your project, but in a nutshell...You start by adding the Spring Web Flow libraries to the project's classpath. Spring Web Flow also needs an expression engine implementation, so you'll also need to add the OGNL or a Unified EL implementation JAR file to the classpath.

Since it's based on Spring MVC, you'll then need to configure a DispatcherServlet in the web.xml file. Using Spring Web Flow's Spring configuration XML namespace, you'll also need to configure a flow executor, a flow registry, a FlowHandlerMapping, and a FlowHandlerAdapter. The FlowHandlerMapping helps the DispatcherServlet find the FlowHandlerAdapter, which relies on the flow executor to execute the flow. The flow executor reads flow definitions via the flow registry. This all sounds like a lot, but it's really only a dozen or so lines of XML in a Spring configuration.

With all of the essentials in place, you're ready to write the flow definition--which is defined as XML (although version 3.0 is supposed to add an annotated Java mechanism for defining flows).

DZone: What makes Webflow easier than competing technologies?

Craig:  Honestly, I'm unaware of anything else that defines flows separate from the implementation like Web Flow does. There may be others, but admittedly my Spring fixation hasn't prompted me to look hard for them. (There may be a 12-step program for people like me, but I really don't want the help.)

But comparing Spring Web Flow with other web frameworks in general, the key takeaway point is that Spring Web Flow lets you define flows as a separate concern from the views and elements that process the flow.

DZone: How do I write a webflow application, in a nutshell?

Craig:  Flows are primarily made up of three things: states, transitions, and flow data. (I feel compelled to refer to the flow data as the flow's state, but the word state is already used to mean something else.)

Referring back to that hypothetical road trip I mentioned earlier, a state is one of those cities, truck stops, or scenic point along the way. Transitions are the roads that connect those points. And flow data is best likened to the souvenirs, soda pops, and empty Frito bags that you pick up along the way.

There are 5 kinds of state: action, decision, view, subflow, and end. Action states typically make calls to some method on a Spring bean. The result of the method can be used to drive the decision on which transition to take to the next state. View states are where the flow stops and lets the user get involved--they display something to the user and give the user a chance to submit data back to the flow. Decision states are binary branches in the flow where the flow could go one way or another based on some condition. Subflow states are ways of breaking flows down into smaller, more cohesive flows. And the end state...well, that's when the flow arrives at its destination.

Writing a Spring Web Flow application involves declaring several of these states in an XML file and then stitching them together with transitions. The parts that actually do any real business logic are just Spring beans. And the views can be almost any view that Spring MVC supports--typically JSP or JSF.

DZone: What is your top tip for developing applications in Spring WebFlow?

Craig: The most important thing to pay attention to is how action states work with transitions. If an action state performs multiple evaluations and if the result of the first evaluation satisfies any of the transitions, then the transition will be taken--and the other evaluations will be skipped. This can be quite confusing if you're not aware of it.

The second most important tip may seem obvious...but it's worth mentioning anyway. Let a flow's business logic take place in Spring beans that are called from action states and keep your view states focused on displaying views. If your view states are performing business logic, then you're probably doing it wrong.

Finally, use subflows. Subflows are good for breaking down larger flows *AND* they're good for dividing a flow into flows that are more cohesive. Even if your flow is relatively small, it may be appropriate to break it into subflows just for the sake of cohesion.

DZone: You're a big fan of Spring - can you explain why there's so much hype around it?

Craig: I'd say that Spring has garnered so much attention in recent years because it's empowering Java developers to build powerful applications using one of Java's simplest constructs: classes. In the beginning, while others were implementing or creating workarounds for ridiculously complex specifications, Spring set out to find simpler ways to accomplish the same thing. That's still true today, but things have shifted and Spring is influencing the standards. OSGi's Blueprint Services, for example, are really just Spring Dynamic Modules, formalized to be part of the OSGi specification itself.