cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [RT] Generalizing the flow
Date Mon, 07 Jul 2003 08:55:15 GMT

Reinhard Pötz wrote:
> From: Christopher Oliver

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

maybe we should separate out some ideas in this paragraph:

- no it is not _only_ about stateless controllers, it is also 
about the 'second approach' (dubbed for now: 'InteractionState') 
and it touches on webcontinuations as well, that is why the 
thread and the wiki talk about 'generalizing'

- as such it is about finding an umbrella API to accomodate for 
all of them by focusing on the similarities while leaving room 
for the differences in the specialized implementations
(like Sylvains example: XSLT is a great and often used 
stereotypical example of what a transformer can do, we would 
however have a hard time looking at all the transformers in the 
cocoon cvs as being stylesheets... mind that the dedicated XSLT 
hardcore believer would probably even succeed at writing down all 
of them as XSLT stylesheets! (even if that would require him to 
write custom extensions))

- see also Bertrand's message praising the 'interfaces': it realy 
is _ONLY_ about generalizing some common aspects between the 
different web app programming models we identified into a common 

- the OO textbook says that this 'generalization' should 
accomodate for higher level of reuse. In this case hoped for are:
   - common sitemap semantix on the one side
   - reusing complete publishing pipes (but more importantly: the 
knowledge to build those)
   - (more socio-engineering level) a general mindset for all 
webapps in Cocoon

- there is this (nasty) bit in the wiki (on purpose) on this very 

> 6. faq
> Q: Why don't we just use Actions for the stateless flow control?
> A very good question indeed. In fact looking at it from the 
 > WebContinuations angle there is quite little distinction to
 > be made between
>          <map:call function="fn_name" /> and <map:act type="start-flow" src="fn_name"
> or even  <map:call continuation="{1}" /> and <map:act type="cont-flow" src="{1}"
> Actions however have been quite largely seen as 'bad', a stigma 
 > they probably got while  the community extended the original
 > Action interface so it could be a havenfor 'arbitrary control
 > logic'.
 > Having said that, we believe that current webapps still have
 > room for a more classic 'stateless flow control'.
 > If we now try to hook in arbitrary logic for the FlowControl,
 > we should envision it having a simple mechanism for doing
 > stateless stuff.
> Rather then wanting us to write up the flow with the map:act 
 > equivalent we would hope for a flow-umbrella API that allows
 > for stateless implementations as well. Small changes in the
 > wording of the sitemap-elements and attributes could
 > achieve a lot:

- you can do anything with Actions (even start and continue the 
flow), and that is probably why a lot of us don't really like 
them: they don't feel like the correct 'generalization' of the issue.

- the proposal hopes to do a better job.

[inverting the proposition]

- history is what it is, but I like this thought-experiment 
anyway: what if InteractionState was in cvs now, and someone came 
along with an other way of addressing the web app flow issue and 
called that new thing 'webcontinuations'

How should we react?
Probably not by proposing: hook it up in the 
start-flow/continue-flow actions, right? :-)

> Cheers,
> Reinhard

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message