Derek Hohls wrote:
Anyone seen the article: http://www.theserverside.com/articles/article.tss?l=SpringWebFlow
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:
http://www.jroller.com/page/kdonald/20050417#my_wife_is_hot_and
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
-- Sylvain Wallez Anyware Technologies http://apache.org/~sylvain http://anyware-tech.com Apache Software Foundation Member Research & Technology Director
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
