- Phonebook - the original sample demonstrating most features (including subflows)
- Sellitem - demonstrates a wizard with conditional transitions, flow execution redirects, custom text field formatting, and continuations
- Flowlauncher - demonstrates all the possible ways to launch and resume flows
- Itemlist - demonstrates REST-style URLs and inline flows
- Shippingrate - demonstrates Spring Web Flow together with Ajax technology
- NumberGuess - demonstrates stateful beans, evaluate actions, and "single key" flow execution redirects.
- Birthdate - demonstrates Struts integration
- Fileupload - demonstrates multipart file upload, set actions, and flash scope
- Phonebook-Portlet - the phonebook sample in a Portlet environment (notice how the flow definitions do not change)
- Sellitem-JSF - the sellitem sample in a JSF environment
News: Spring Web Flow 1.0 is out
Spring Web Flow 1.0 has been released. See the official springframework.org release launch page. Spring Web Flow is a next generation web application controller framework that runs on Java SE 1.3 or greater, and Java EE 1.3 (Servlet 2.3, Portlet 1.0) or greater. The framework allows developers to define user interaction and application behavior as reusable, high-level modules called flows. The product is particularly suited for implementing wizards and other guided processes. You can download the release here and view the on-line documentation. Existing users running on previous versions should checkout the 1.0 upgrade guide. Ten sample applications ship with the release and are available on-line for viewing:
- Posted by: Joseph Ottinger
- Posted on: October 26 2006 11:57 EDT
- Re: Spring Web Flow 1.0 is out by Sutham Rojanusorn on October 26 2006 12:10 EDT
- Re: Spring Web Flow 1.0 is out by Jacques Ledoux on October 27 2006 05:25 EDT
- JSF integration by Martin Jelen on October 28 2006 06:27 EDT
- Re: Spring Web Flow 1.0 is out by legolas wood on October 31 2006 07:08 EST
The full 1.0 release announcement can be found at http://www.springframework.org/go-webflow Erwin
I did an interview with Keith over at InfoQ.com Keith Donald Discusses Spring Web Flow 1.0 - Bringing Reusable UI Flows to Java Web Apps
I have been experimenting with Spring Web Flow for almost a week now and I am very impressed with this framework. IMHO it addresses one of the most time consuming and difficult to test aspect of web programming. Usually, the code that controls the page flow is scattered all over in a web application's each and every page. By extracting all the flow logic code into XML or builder classes, the framework boost productivity and testability by an order of magnitude. Congratulations to all the people involved in this project. JL
It's also a great compliment to the BPM/workflow apps. The webflow doesn't address a business process app concerns, it can compliment it in a great way. A business process would then be a logical representation of higher level tasks that need to be accomplished, with each task being abstract enough to facilitate multiple interfaces. A task of say, adding a user requires a particular state to complete. As a web service client, the state can be submitted at once, in an web app interface, this might be a consolidation of data collected through multiple screens, though, webflow can be used to logically represent the workflows within a web application domain and keep the business process representation clean. The programmatic runtime configuration of webflow allows that to also be done dynamically at runtime, though allowing for adaptive systems and workflows. Congrats to the team, awesome product. Ilya
First, congratulations on the release! I like the ideas behind Spring Web Flow and I'm looking forward to using in in practice. I'm especially interested in integration with JSF and a little disappointed with the online SellItem-JSF example that shows just that - when I use the browser back button and re-send any the forms, I get just an exception stack trace - and that doesn't happen in the non-JSF version of the same example.
The sellitem-jsf sample is using a SimpleFlowExecutionRepository which does not 'handle' back button use correctly in all cases. The sellitem-jsf intro states this: "Note on continuations: The original sellitem sample shows continuations in use, in the words of the intro, "Using continuations to make the flow completely stable, no matter how browser navigation buttons are used." This JSF version of sellitem is currently set to use normal session storage. The JSF Web Flow integration does support the continuation storages..." Erwin
Sellitem JSF doesn't use continuations by default to match the default JSF behavior of storing UI component state in the session. Currently (by default), JSF component state is managed by JSF in the session, and flow execution state (model values) are managed by Spring Web Flow. So, since JSF UI state is put in the session by default, that's why we use the "Simple" storage by default that also stores execution state in the session (and without continuations that allow back button use). With tha said, you can turn on JSF continuation storage to get browser back button behavior by dropping in a continuation-based flow execution repository bean in the backing Spring content. The JSF Flow Phase Listener will detect it and use it. One of the goals of the 1.1 roadmap is to look at several approaches to leveraging JSF UI components in a SWF environment. The approach we currently take has JSF drive the overall request lifecycle, with SWF calls fitting in within specifc JSF listener methods. One concern I have about this approach is we can't leverage SWF's simpler flow executor lifecycle directly, and have to "fit into" the JSF lifecycle--which was fairly difficult for us to get right (we had to determine what generic listener methods to override, and deal with code being spread around several JSF hooks (code which is centralized in the FlowExecutor for leverage by other clients like Spring MVC)). The other approach we want to investigate is having SWF drive the JSF UI component lifecycle, to allow for usage of JSF components within SWF's simple execution model. One positive I know this approach will have is it will make it natural to have UI component state managed by SWF, instead of managed by two different systems as it's done now--because an SWF flow execution will be the container. I hope this helps provide some background on the JSF integration and status! There is a lot of interest in the 1.1 roadmap in continuing to enhance this integration to combine the strengths of both technologies. Keith
Thanks for the information, I'll check that out and I'm looking forward to even better integration of the two technologies in future versions.
Does spring webflow use some standard flow language ? does it has some flow designer or we should use 3rd party flow designer ? thanks
SWF has it's own flow definition language, designed specifically to allow you to easily and elegantly capture flows in XML. The Spring IDE (http://www.springide.org) team is working on a graphical SWF flow editor.