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 Sun, 15 May 2005 21:52:43 GMT
thomas wrote:

> --On Freitag, 13. Mai 2005 12:07 Uhr +0200 Sylvain Wallez 
> <> wrote:
>> 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.
> as i understood it the results of a flowscript-operation don't 
> generate sax-events. so you can use flowscript only at the end of a 
> pipeline. is that true?

Yes, a flowscript doesn't generate sax events, and no, it doesn't come 
at the end of a pipeline. Rather the contrary, as the flow is the 
controller in the MVC (model - view - controller) pattern.

Actually, Cocoon is sometimes called "MVC+" as it has two levels of 
- a level is the sitemap, a controller that maps requests to some 
processing (be it a flow call or a pipeline)
- another is the flow, which manages the interaction of the user with 
the business logic across successive pages.

So the flow takes some decisions according to the application state, and 
then calls a pipeline using an internal request (i.e. using the 
"cocoon:" protocol).

> and is it equally true for all 3 flow-implementations mentioned above?

Yes, they all behave similarily: do some stuff and call a pipeline. They 
differ either in the programming language used or in the way interaction 
state is saved across requests.

> in that case i would think that some logic within the sitemap (the 
> infamous "if") wouldn't be so bad (for very comlex problems one could 
> still decide to leave the sax-stream and use flows). but i might very 
> well overlook something obvious or essential.

Actually, there are some ifs already in the sitemap: <map:match>, 
<map:act> and <map:select> are control structure, and are similar to an 
"if" or a "switch". But the purpose of these control structure is to 
allow some simple conditional building of pipelines, and complex 
conditions should be computed at the controller level, i.e. in the flow.


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

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

View raw message