cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <reinhard_po...@gmx.net>
Subject RE: [RT] Generalizing the flow
Date Mon, 07 Jul 2003 11:46:36 GMT
From: Sylvain Wallez

> Reinhard Pötz wrote:
> 
> >From: Reinhard Pötz
> >  
> >
> <snip/>
> 
> >>>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 
> control.
> 
> 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.

Ok. I understand. Thank you!

> 
> 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 ?

With your latest explanations I (and I hope others too) have a good
overview what your proposal is about and why you want it. I think we can
go for a vote on the Flow, FOM and the JavaScript/Continuations
implementation. I'll prepare it and post it this evening or tomorrow
morning (CET). So we should have enough time to wait for the results and
should be ready for beta at the beginning of the next week.

Cheers,
Reinhard


Mime
View raw message