cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Generalizing the flow
Date Mon, 07 Jul 2003 08:39:47 GMT
Reinhard Pötz wrote:

>From: Reinhard Pötz

>>>Even so, I really don't like your names. <map:call> made perfect sense when
calling a continuation or function (since they are actually callable). I don't quite get what
"calling" a "state" means.
>>I would be interested in this too because I'm wondering what can you do with a plain
Java controller what Actions can't do for you? Or do you _only_ want to make a shift away
from actions?

Actions are a general purpose "do what you want in it" interface, and as 
such have been used for very various things ranging from environment 
test (such actions are actually a matcher), business logic and... flow 

The main purpose of having the flow identified by its own statements was 
to clearly separate flow-related actions from other kinds of actions. 
Both for architectural cleanness (SoC) and marketing (the recurrent "MVC 
in Cocoon" and "Struts vs Cocoon" questions).

This is explained in the first FAQ in the wiki page. Briefly, is there a 
difference between :
- <map:call function="fn_name" /> and <map:act type="start-flow" 
src="fn_name" />
- <map:call continuation="{1}" /> and <map:act type="continue-flow" 
src="{1}" />

Not really. So all the <map:flow> and <map:call> stuff is really about 
is separating the particular flow control concern form the 
general-purpose Action interface.

So the purpose of this renaming is allowing other implementations of 
flow controller in <map:flow> instead of forcing them to go through 
<map:actions>. Why should we forbid the flow to be implemented using 
Struts (an important point for people migrating from "plain" J2EE to 
Cocoon) or more fancy things such as a rules engine ?

>I think we need some more time to investigate these issues. Is it a problem if we decide
to change some class names and sitemap elements after we released a beta?
>I'm asking because beta1 should be released in a week and I think it is too early to decide
*NOW* if we should follow Sylvain's/Marc's proposal or not.
>What do you think?

Remember : "beta" means API stability. Of course, we can provide a 
compatibility mode, but since this is really about renaming a few 
things, this isn't a big work. Ready for a vote ?


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message