cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: RT: map:call as generic non-redirecting controller code
Date Fri, 06 Jul 2007 12:26:46 GMT
Grzegorz Kossakowski skrev:
> Ellis Pritchard pisze:
>>> Do you mean that you would have flowscripts like:
>>> myFlowAction() {
>>>   var result = calculateSomething();
>>>   setReturnData(result);
>>> }
>>> I would much prefer to just use the return value of the flowscript:
>>> myFlowAction() {
>>>   return calculateSomething();
>>> }
>> Agreed, the former is clumsy, but easier/less disruptive to 
>> implement, the latter is much more natural and what I was originally 
>> aiming at.
>> Ok, I'll look out for further feedback, but otherwise submit a patch 
>> using the direct return method for people to review.
> 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>
I got the impression that Ellis leaned towards using a special flow 
action instead.

> 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?
When you call a pipeline within a flowscript the object model is 
extended with the "bizData". The business data is then available in 
JXTemplate. I think we should use the same mechanism for "flow actions". 
The return value from the flow script is the business data. This should 
then be inserted in the object model see 

By doing that we can use a JXTemplateGenerator after the action and 
extract the needed data.

Of course it should be possible to obtain data from some protocol as 
well. But in many cases it is quite inconvenient to serialize business 
beans to XML and the extract the needed fields with XSLT, it might be 
easier to just access the fields directly with the expression language 
in JXTemplate.


View raw message