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
org.apache.cocoon.components.flow.AbstractInterpreter.forwardTo
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/components/flow/AbstractInterpreter.java.
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.
/Daniel
