The first public release of the open source Spring Web Flow system is available. Spring Web Flows is a specialized controller for the Spring MVC framework that allows you to capture the page flow in a web application using a simple XML web flow definition.

I have also written an article to explain the web flow concepts in more detail and to illustrate the system using a sample application.

Check out the Spring Web flow home page for more details and download links: http://www.ervacon.com/products/springwebflow

Any feedback would be much appreciated!

Erwin

Great addition. Wrong choice of contacts in the phone book.

Ask Andrew Tanenbaum:
http://www.electoral-vote.com/

In the event of another attack on the Website, please try http://www.electoral-vote3.com , http://www.electoral-vote4.com , http://www.electoral-vote5.com , etc.
But stick with the main site if it works. After an update, half a dozen 60-MB files get shipped all over the country and it takes a while to get there, so the main site is always more up to date. I just upgraded each of the main servers to 2 GB each. They should be able to handle 500-1000 requests/sec each now.

(btw I knew a web site where people all over the world were "voting" for this election. It was often hard to reach but interesting to see what we can do now a days with a server and a database).

.. and pageflows, aka statemachines are not at all suitable for modelling user interfaces.

I fully agree when you say XML is not a programming language. Still, I have noticed that many novice programmers seem to be better at producing quality XML than quality source code...

A state machine is not suitable for a GUI, but I'm not so sure about page flows in a web app since you're always dealing with a request/reply system. Anyway, I've found thinking of a web app in terms of a page flow much more intuitive than cutting everything up in individual request/response couples.

Erwin

o the name-value-pairs of the request can be considered lowlevel events
o a dispatcher is delivering them to the components
o components adapt their state and fire high level events
o the reload manager (aka repaint manager) keeps track of dirty components
o the look and feel generates (browser-specific) code

I agree with you, page flows are a lot more intuitive than dealing with plain request / response. But the programming model of - lets say: swing - is even more intuitive.

xml is not a programming language.. and pageflows, aka statemachines are not at all suitable for modelling user interfaces.

What, exactly, is wrong, apart from this not being con:cern - which you are the contact for?

Geir

So what exactly is so constructive about your comment? I could have mentioned wingS, which is an alternative for page flows and which I'm a contact for, too. Well, I didn't, because I don't like that kind of comments.

So what exactly is so constructive about your comment? I could have mentioned wingS, which is an alternative for page

The bit where I ask "exactly what is wrong". As it stands, your comments are negative statements about a "competitor" that I am not able to follow.

I see you have answered this elsewhere now. I still don't agree with you when you say that "xml is not a programming language". It isn't, but if you need a syntax to flatten a directed graph, it is as good as any other syntax.

I don't know Swing. I have got no clue wether it is better or worse than anything else.

I still don't agree with you when you say that "xml is not a programming language". It isn't, but if you need a syntax to flatten a directed graph, it is as good as any other syntax.

It is good at this time, but if you will add guards, scripts then it become not so good. I am sure more stuff will be added if people will start to use it, it need graphical editor, documentation generator, testing framework ... All projects start from simple goals :)
But I think idea is good, FSM is very trivial to understand and it must help for web UI.

.. and pageflows, aka statemachines are not at all suitable for modelling user interfaces.

Why? Isn't that like saying you can't make integrated circuits using NAND gates?

It certainly looks very interesting, and is an approach that we've been considering previously (building complete controllers out of a collection of re-usable elements, and defining the connections between them and the controller workflow externally). I particularily like being able to do away with the whole bind-and-validate procedure unless we actually need it.

A couple of comments from a ten-minute look at the guide and the javadocs (which are very clear btw):

How well does it tidy up the session after itself? I quite like the spring unbind/rebind approach to command objects, but you have to jump through hoops if you want to leave and rejoin controllers cleanly. Are unused webflows cleaned up nicely, or do they persist for the lifetime of the session?

The action you execute on a webflow is governed by a parameter with the well-known name _event. The problem with this is if you want to determine which action you perform by using differently-named submit buttons. Probably the wrong place to bring this up, but I think it would be an improvement to stipulate a prefix for the action name (eg. _event_) and that the rest of the parameter name be the name of the action to perform (eg _event_search -> search).

Regarding cleanup: a flow cleans up after itself when it terminates (reaches an end state). For the moment there is no 'flow timeout' or anything like that, so unused flows remain untill the session is invalidated. I have been thinking of adding flow expiry, but right now it's not implemented. Another option is implementing an action that cleans up unused flows in the session when a new flow starts (ofcourse avoiding to kill the parent flow if it is a sub flow). This would be a good approach in applications where there is only one 'top level flow' active at the same time.

About the _event parameter that is used by the controller: maybe I should add something like the "MethodNameResolver" used by the Spring "MultiActionController". I considered this for a while but ditched it for now. Notice that the WebFlowController class has a method "getParameter" that you could redefine to change the parameter lookup system.

Thanks for the feedback!

Erwin

Sorry to sound negative, but I don't see anything here that OSWorkflow doesn't already offer. Is this reinventing the wheel, or is there something I'm missing?

For a more novel approach to this problem, have a look at Cocoon's FlowScript. It's the best page flow solution I've seen by a long way.

You're not missing anything. The Spring web flow system certainly is not a novel way of defining page flows. I created it because I was looking for a simple and light weight page flow system tightly integrated with Spring. But all I could find was general purpose work flow implementations, like OSWorkflow or jBPM.

Erwin

You're not missing anything. The Spring web flow system certainly is not a novel way of defining page flows. I created it because I was looking for a simple and light weight page flow system tightly integrated with Spring. But all I could find was general purpose work flow implementations, like OSWorkflow or jBPM.Erwin

Fair enough. I haven't used jBPM yet so I can't comment on it, but I have done a (little) bit of work with OSWorkflow and that seemed fairly lightweight to me - especially compared to IBM's Process Choreographer. I was able to integrate it with Struts fairly easily, which I believe Spring MVC is similar to. I'd be interested to know what it is about OSWorkflow (et al) that makes it non-lightweight, or otherwise bad enough to drive you to write your own. I'm likely to be doing some more work with it soon, so any info like that could be useful if you don't mind sharing it.

Sorry to sound negative

Please do not be sorry. Enough sanitized congratulatory posts. Only healthy critique keeps things alive and agile.

Sorry to sound negative, but I don't see anything here that OSWorkflow doesn't already offer. Is this reinventing the wheel, or is there something I'm missing?

I don't think the comparison is exactly fair. The workflow portion of Springwebflow is little more than a simple state machine, whereas OSworkflow (despite having a pretty unpleasant API) is far more capable (split, joins, functions, triggers, persistence etc). However, it looks to me like the goal of this project is to make Spring's web-tier more capable.

While I like Spring's MVC a lot, I do find myself inheriting to customise behaviour, rather than using delegation and composition. It struck me that it would be a very good idea to take the various bits of controller logic and string them together using a workflow engine to control page flow. That's what this project does that OSWorkflow doesn't - integrates with and controls Spring's MVC components, and provides a strategy for composing controllers more flexibly.

A potential enhancement would be to make the workflow portion of Springwebflow an interface to allow something like OSWorkflow to be dropped in when extra features are needed (eg. for workflow persistence).

For a more novel approach to this problem, have a look at Cocoon's FlowScript. It's the best page flow solution I've seen by a long way.

I've looked at the above link and its certainly intriguing - if I follow the example correctly your process flow is modelled as a server-side javascript that effectively pauses and resumes as requests are received and processed. Neat if you happen to be using cocoon (never touched it myself), and I'd like to see a more complex use case than that in the tutorial. I can't say I'm 100% convinced, but that might just be because I've got Springwebflow to play with at the moment... plus I thought the javascript was client-side at first and it nearly gave me heart failure ;).

if I follow the example correctly your process flow is modelled as a server-side javascript that effectively pauses and resumes as requests are received and processed.

What is server-side javascript??

if I follow the example correctly your process flow is modelled as a server-side javascript that effectively pauses and resumes as requests are received and processed.

What is server-side javascript??

JAVA, of course!

What is server-side javascript??

JAVA, of course!

Hardly. It is pretty much what its name implies. It is Javascript that runs in the server, not on the client.

What is server-side javascript??

JAVA, of course!

Hardly. It is pretty much what its name implies. It is Javascript that runs in the server, not on the client.

Aha! They wanted JAVA on the browser.. JavaScript it is. Now back to the Servers.. huh, Nice :)

if I follow the example correctly your process flow is modelled as a server-side javascript that effectively pauses and resumes as requests are received and processed.

Yes. It effectively allows you to use web pages like modal dialogs within your script. They could have chosen a nicer language than JavaScript, but the idea itself is excellent IMO.

There was talk of a Java version as well, but that was progressing slowly last time I checked. There was also talk of separating FlowScript out into a separate project, but it's been a while since I bothered to follow the Cocoon mailing lists so I don't know what's happening with that now either.

There was talk of a Java version as well, but that was progressing slowly last time I checked. There was also talk of separating FlowScript out into a separate project, but it's been a while since I bothered to follow the Cocoon mailing lists so I don't know what's happening with that now either.

The javaflow block is part of Cocoon 2.1.5.1 and does work but has some limitations. Mozilla Rhino has incorporated continuations (at the heart of what makes flowscript work) into their project.

Sorry to sound negative, but I don't see anything here that OSWorkflow doesn't already offer. Is this reinventing the wheel, or is there something I'm missing?For a more novel approach to this problem, have a look at Cocoon's FlowScript. It's the best page flow solution I've seen by a long way.

Yes, they have developed a version of Rhino Javascript with continuations. Makes any asynchronous interaction look just like synchronous. Very simple to model.

ATCT from Velare does the same thing but for Java. It has a thread class which is basically a JVM in it's own right, but allows you to pause, serialize and resume execution state. Had a play with it. After that, you realise how simple interaction flow should be.

Kit

This software is released under which license? Is it opensource?

"The first public release of the open source Spring Web Flow system is available."<br>
Duh! :)<br>
Well, but I couldn't find anything about its license.

Ah de license, that kinda slipped my mind. This must be the first open source project with good docs but no license :)

Anyway, for now it is "free for all". I'll put a BSD license on it for the next release to clarify the situation. I also added a note about this is on the home page to inform people.

Erwin

Why don't you use the ASF license, like Spring?

It looks good. It resembles what we've done internally in our company by extending Struts instead of Springs MVC framework. I'm glad to see a solution for Spring :)

I like the way you describe the flows using Xml. What I'm missing is a special way to handle backward navigation functionality, where the user easly step back a single step in a flow by issuing a back navigation. You handle the subflow back nicely (using the end construct), but I'm missing backwards navigation between states in a flow.

What we did was to allow programmers to register special events handlers, which were added to the event processing chain. This way event handlers could handle specific event keywords generally.
To aid the back functionality we added a HistoryStack, which by adding a visit id to each page also can handle browser back button intervention, helps us to move back to a previous state by just issuing a back navigation. Each flow doesn't have to handle this specifically, it's handled by the framework.

/Jeppe

The point of this flow controller is that you can make context-sensitive requests. Thisway it possible to decouple the forms from there actions, (not mapping) its up to the the controller to delegate requests.

Another framework that is able to handle WebFlows is "WebFlow Navigation Manager": http://wfnm.sourceforge.net . It can be used on top of any other web framework or even with servlets and JSPs. It also allows automatic http session cleaning.

This is interesting stuff.

The latest version of AndroMDA includes a cartridge for generating JSPSs and Struts actions from a UML activity chart. It would be interesting to see if the same could be done for this framework as well. A quick scan of the docs suggests there are many similarities between the two. There is also a Spring cartridge so it would fit well into that.

Kit

This entire framework has been built from bottom up around the
concept on self describing business object. This naturally lead to pageflows and the web

Quick Blog (screenshots) and a phone book clone.. :
http://zxf.sourceforge.net/blogger.php?page=news_photo&id=1099420856

The essential pattern :
https://theserverside.com/patterns/thread.tss?thread_id=26377

PS : Purest will not like this framework, however people
who want productivity on database orientated system will love it.

... but completely irrelevant.

Seriously, what does this have to do with the current topic?

Lets recap:
   - Springwebflow is a very small (10 classes) and potentially useful addon to the existing Spring MVC framework to enable a different approach to working with web controllers.
   - ZX is an everything-but-the-kitchen-sink framework for database-driven development - it looks like its supposed to quickly generate standard screens for basic database operations, and is more like Naked Objects or HtmlDB than anything else.

Don't get me wrong, I don't want to denigrate ZX (I'm not in a position to) - I've only read some of the (truly expansive, and VB and COM-centric) documentation and I'm still quite baffled by it all. The only similarity between the two projects is that they both use the phrase 'page flow' at some point.

This truly is comparing apples to tractors.

Well it was developed on a Mainframe framework so it is not really COM+ or VB centric, it just so happened that the documentation you read is actually on the VB implementation (There is also work on a .Net(??) port) .
The core comcepts are in a no way language specific, it just
so happens that the prior implementation is VB based. At the moment we are moving away from that to Java. I myself am not a VB developer and was only involved in the port from one architecture to the other.

The funny thing is that the core concepts of the framework is very simple ie : Self Describing Business objects. It is just that zX itself is very layered. So eventually you have a full system, including Graphical Pageflow editor, Mail handlers, Document builder etc. etc.. All of which a language neutral. ie : you can share the same pageflow/business objects.

Unfortunately people that are concerned about purity and procedures over actually delivering quality software seem to get distructed by some of the short comings or previous implementation.

It is a pity more people do not take up the Agile Manefesto.
We are going to open source the core java code, but i do not
expect much uptake until we have some demos, install scripts and user friendly (and java friendly :) ) documentation.