cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: Flow or actions?
Date Wed, 14 Jan 2004 17:41:00 GMT <> asks:

> Although most of the arguments are clear, they also raise 
> more questions :-)
> > I don't know if I get all arguments but at least some:
> > 1. Both actions and flow scripts were designed for the
> > controller part.
> > 2. Actions were often misused, so a new concept was searched for.
> Could you give an example of this "misuse"?
> > 3. Interpreting (flow script) vs. compiling (actions).
> > 4. Procedural style of the flow scripts is nearer to flow 
> control. 5. 
> > Support of continuations with flow scripts.
> From a newbie point of view: the idea behind it is fairly 
> easy to grasp, but when trying to figure out why it doesn't 
> work as expected (e.g. with Woody
> forms) it is very incomprehensible. But maybe that is related to 6.
> > 6. Less delivered code for flow scripts while there are many actions
> > available.
> > 7. Better separating of concerns for flow scripts.
> > 8. Therefore less sitemap readibility (the sitemap flow is not that 
> > obvious, because parts of the logic is in the flow script).
> Thanks for the explanation. Can you, or anyone else, give 
> ideas as to when to use actions and when to use flow? I don't 
> have the feeling that they are interchangeable. On the other 
> hand I feel that using both actions and flow in a single 
> webapp will add to the complexity.

Use flow.  Embed your business logic in Java classes that you call from
flow, but use flow.

For many actions it's pretty much trivial to convert actions to flow. In
the flow you can call an action (or other Java business logic) as:

    var handler =;
    return handler.act( cocoon );

In your action you then have:



    public boolean act( FOM_Cocoon cocoon ) 

Now you can pick up cocoon.getRequest() or cocoon.getObjectModel() and
probably most of the other things a normal action handler might need.
I'd note that it might seem nice if it was possible to trivially pick up
all the things an action handler has on a standard "act" method, such as
the redirector; then you could just have this new method call the
existing act method.  However, I'd recommend moving redirects out of the
Java classes and keeping all the flow logic in the flow. In our case we
return a boolean to tell the flow whether the action "worked" and this
helps enforce the separation of business logic from flow logic.

View raw message