InfoQ sat down with Keith Donald and Jeremy Grelle of the Spring Web team to discuss the release of Web Flow 2.0.0.RC1, the first production release candidate for the next major release of Web Flow. Web Flow is an extension to Spring MVC for implementing flows in a web application.
What is new in Web Flow 2.0?
Web Flow 2 has seen numerous significant new features, such as:
Progressive Ajax
First and foremost, Web Flow 2 introduces Ajax event handling capabilities. You simply handle an Ajax event like you would any other Web Flow event, and after handling your flow can request that certain fragments, or partials, of the UI be refreshed. You can see this partial rendering support in our Spring Travel example when you page through the search results table and when validation error messages are displayed in the UI.
What is interesting about our Ajax support is it degrades gracefully when Javascript is not available on the client. Try accessing the Spring Travel app and turning Javascript off. The application should still work.
So our Ajax support actually consists of two pieces: the Web Flow integration server-side for detecting an Ajax-enabled client and rendering fragments as requested, and a client-side piece for actually submtting Ajax requests and linking the response fragments into the page. The client side piece we provide is called "Spring Javascript", which is a new module included in the Web Flow distribution that builds on Dojo 1.1 underneath to provide a clean, consistent API for things like Ajax and progressive enhancement.
Deeper Integration with Spring MVC
The relationship between Spring MVC and Web Flow is complementary: Spring MVC is the base platform for web application development, and Web Flow is a Controller extension that plugs in for implementing flows (aka conversations), which are stateful user interactions that span more than one request.
So Web Flow 2 deepens its integration with the popular Spring MVC platform. It is now easier for stateless Spring MVC @Controllers to call Flows, and for a Flow outcome to be mapped to a Controller. You can see this in the "mvc" flavor of the Spring Travel reference application, which shows a mix of @Controller and flow usage. In that flavor, the "shop" or search parts of the site are implemented using stateless @Controllers, offering full bookmarkability, and the booking portion uses a stateful Web Flow, providing per-window isolation of a booking application transaction. It is a nice fit.
Refactored and Expanded JSF Integration
In Web Flow 1, you might have used Web Flow in the context of a "traditional" JSF application, where JSF's FacesServlet was in the driver's seat, and Web Flow attempted to fit in at the right points using a PhaseListener and NavigationHandler. This was a difficult integration task for us, and exposed several subtle issues that were difficult to address like exception handling, concurrency, security, and persistence context management.
In Web Flow 2, the relationship between JSF and Spring Web has been inverted. Inversion-of-control is a good way to think about it, actually. Instead of fitting Spring into JSF's world, we now fit JSF into Spring's world, inside a familiar Spring MVC DispatcherServlet by using native Spring MVC and Web Flow extension points. Basically, we have taken the bread-n-butter of JSF, which is its UI component model, and brought that to the Spring MVC and Web Flow controller models as a View technology. An immediate benefit of this integration approach is you get to reuse all your existing Spring MVC infrastructure: your URL mappings, your exception handling policies, your Spring security policies, and you can quickly combine that with JSF components to build your UI. This brings you all the JSF component libraries available today in an manner that feels natural to those with a background in web MVC concepts.
One might ponder if with such a unique integration approach, there would some catch. So far we haven't found it. We have successfully demonstrated you can run all of the major JSF component libraries in a Spring Web environment. In addition, we have built our own small component library called "Spring Faces" that uses Spring Javascript to provide a set of Facelet tags for declarative client-side validation and Ajax. The faces flavor of the Spring Travel reference application shows this library in action.
Spring Security Integration
Web Flow 2 introduces support for securing flows. Simply annotate a flow, state, or transition as "secured" and a SecurityFlowExecutionListener will make sure the current user has the necessary authorities to start the flow, enter a step, or initiate an event, respectively.
Simpler Flow Definition Language
You wil also find the core language for defining flows to be much simpler in Web Flow 2. For our Spring Travel reference application, for example, the version based on Web Flow 1 consisted of ~200 lines of flow-related application code across 6 artifacts. The latest 2.0.0 RC1 version, which delivers more integrated functionality, consists of only 93 lines of code across two artifacts, a 50% reduction with 4 less files to maintain. You can see this for yourself by comparing a version 1 flow with its version 2 equivalent.
New Modularity Features
We have also expanded upon the concept of a flow as a "reusable, self-contained application controller module". Now by default, a flow and all of its dependent resources, such as views, messages, and helpers, are packaged together. Organizing code by domain responsibility is a best practice, and in Web Flow 2 we are trying really hard to make this the easy practice. You can see an example of this here. Within the booking directory, the flow's views and message bundles used to support internationalization are packaged together.
What are the philosophies behind this release?
I would say a major philosophy is definitely ease of use. Web Flow 1 is a mature framework with a lot of features, but Web Flow 2 goes significantly further by making the common tasks easier to accomplish using a simpler flow definition language overall. Integration is definitely a theme, as we introduced first-class integration with JSF, Spring Security, the Unified EL, Spring Javascript, and Rich Faces. As mentioned, our integration with Spring MVC has improved as well, and I do think Web Flow 2 really reasserts Spring MVC's role as the base platform for Spring web applications for which other extensions can plug in.
What are the major changes that one can expect moving from 1.0 to 2.0?
The simplifications in the flow definition language are the main changes folks can expect. So to assist customers in upgrading from 1.0 to 2.0, we have included a WebFlowUpgrader tool in the distribution that automates the conversion of version 1 flows to the new version 2 syntax.
For a complete list of changes, we recommend all 1.0 users check out the new reference guide as well as the 2.0 reference applications which are designed to show best practice. We are committed to making the 2.0 upgrade experience as pleasant as possible for our community.
What sort of tool support is there for Spring Web Flow?
The Web Flow definition language is XML-based, so the first tool you need is a good, schema-aware XML-editor. Web Flows typically delegate down to a Java domain model and service layer to carry out application behaviors, so you definitely need a good Java IDE. Beyond that, the Spring IDE project provides a superb Eclipse plugin that allows you to visualize the configuration of your Spring Web application, and also includes a graphical Web Flow editor. The Spring IDE team is currently working on dedicated Web Flow 2 support. Christian Dupuis, the lead of Spring IDE and our recently announced SpringSource Tools Suite, has plans for his team to introduce the new Web Flow 2 support in May.
The SpringSource Tool Suite goes further by providing a fully integrated development environment for building Spring Web applications which include flows. Our team has already authored several task-focused tutorials and runtime error resolutions as part of the suite's beta release, and we will introduce more in the future. Also, the recently announced SpringSource Application Management Suite will introduce runtime visibility into the Web Flow execution engine in its upcoming 1.0.0.RC2 release.
What will future development of Web Flow focus on, and what is targeted for the 2.1 release?
We have a lot planned for 2.1. Declarative model validation is a popular topic, and one we will address in the 2.1 release. In 2.0, we already provide support for auto-detecting and invoking model validators on postback, so the foundation is there. The next step is to allow validation constraints to be expressed declaratively against your model, and for those constraints to be enforced on both the client-side and server-side.
I think you'll also see us explore scripting languages as means of defining control flow in the 2.1 release. Grails, which builds on the Web Flow 2 engine, has already shown that a Groovy-based flow definition language is viable, and we are working with Graeme on incorporating his GroovyFlowBuilder back into Web Flow proper. In addition, I think there is real opportunity in broadening the flow definition language into what I call a "site definition language", where you can define an entire site macrostructure declaratively, where some of the site elements are flows. Jesse James Garrett's Visual Vocabulary is really an inspiration for some of these ideas, and I think there is a lot of interesting work to do in this area.
We are also working really hard to make sure the innovation that's happening currently inside the Web Flow 2 vehicle finds its way back into the Spring Framework itself where it makes sense. For example, we are working right now on bringing all the Ajax features you get with Web Flow and Spring Faces to developers of existing Spring MVC applications that employ JSP and Tiles.