cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: RT: map:call as generic non-redirecting controller code
Date Fri, 06 Jul 2007 15:51:37 GMT
Grzegorz Kossakowski wrote:
> Just to be sure, do you want to implement something like:
> <map:match pattern="sth">
>   <map:call function="prepareData"/>
>   <map:generate src="..."/> <- some protocol to obtain the prepared data
>   [...]
> </map:match>
> Such construct introduces new semantics for sitemap because data 
> returned by <map:call> will be available _outside_ <map:call> element. 
> Now it is important what is the scope where the data will be visible. 
> Have you thought about it already?
Actually, I have been thinking about this for a while as I have been 
toying about trying to figure out the best way to integrate Spring 
webflow with cocoon. One option was to use the Interpreter interface 
(which seemed very awkward, since this isn't really an interpreter) and 
use map:call.  IIRC, it seemed that most (all?) of the flowscript usages 
I looked at don't follow the paradigm above. Rather, map:call is sort of 
an end point. It invokes other Cocoon pipelines to generate views but a 
pipeline doesn't follow it in the sitemap. I actually prefer this over 
the above. All this syntax does is provide a little bit more flexible 
action while still encouraging users to use the sitemap as the complete 
controller, even for business logic, which I hope we all know by now is 
a mistake.

Instead, I would simply like to see map:call expanded so that the target 
function can be a bit more generic than an Interpreter (i.e - it is 
easier to implement things like the JSF block, which uses an action or 
Spring webflow).


View raw message