cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Spring "web flow" vs Cocoon Flow/Continuations
Date Fri, 13 May 2005 10:07:06 GMT
Derek Hohls wrote:

>Anyone seen the article:
>and can comment on how these two approaches might be 
>compatible (or in conflict?)

These approaches are similar in that both save the interaction state, 
send its ID to the browser, that sends this ID back to the server to 
restore the interaction state.

The implementation of the interaction state and the definition of the 
flow are however really different:
- Flowscript and Javaflow use continuations that hide most of the state 
management problem, allowing to write the interaction in a regular 
programming language.
- Spring uses a declarative approach to define the different states, 
actions and transitions.

Now which one is better?

3 years ago, the cocoon devs were discussing "flow maps", and addition 
to the sitemap to define page flow using an XML grammar. We always ended 
up with verbose XML languages having control structures (the infamous 
"if"), and then some people came with continuations, at first is Scheme 
(a Lisp dialect - eck!) and then Javascript, and later pure Java.

Having a real programming language allow to *very easily* write complex 
page flows, as you can use all the language's features for control 
structures, and simply use regular variables to store the interaction 
state. Amazingly easy and powerful.

The main advandage I see to a declarative approach is that it allows to 
build visual tools (i.e. graphical editors) to design the flow. But the 
underlying XML files are very likely to be a real mess in realworld 
complex use cases.

Note however that Cocoon's flow engine is pluggable and that we have 3 
versions of it today:
- flowscript, using Javascript to define the flow (business logic should 
be kept in Java)
- javaflow, a pure java implementation
- apples, an experimental implementation (used in Daisy IIRC) which may 
be actually closer to Spring's approach.

>PS for an interesting choice for a demo of "saving state" - see:

Dead easy with flowscript too...

>BTW, why is that other web application frameworks such as Struts
>Tapestry, WebWorks etc are *always* mentioned in these types of 
>articles and Cocoon just never makes an appearance?

Because, as Sebastien outlines, we're bad at communicating, and should 
definitely improve in this area.


Sylvain Wallez                        Anyware Technologies  
Apache Software Foundation Member     Research & Technology Director

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message