cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: RT: map:call as generic non-redirecting controller code
Date Fri, 06 Jul 2007 17:47:14 GMT
Ralph Goers pisze:
> 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.

I understand your point and even share it. ;)
I asked about that syntax because of deja vu effect (I have been reading some related discussions
in archives to see what people said earlier).

After re-reading Ellis'es original proposal I would say that I'm more than fine with it. Go
ahead, Ellis!

> 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).

What more generic than Interpreter interface you need?

Grzegorz Kossakowski

View raw message