On 5 Jul 2007, at 22:33, Daniel Fagerstrom wrote:
Ellis Pritchard skrev:
Hi,
Ok, that looks interesting (head spin); presumably that's a 2.2.
thing with no plans to port back to cocoon 2.1.x?
Adding a new non-void method to Interpreter alongside the old one
does seem a bit pointless; currently I've implemented the old
method as just calling the new one: unless this API method is
really set in stone, it would seem to be better to re-factor the
signature of the existing method.
I wouldn't have any problem with such a small refactoring of the
API. But I have no expertise in "API development" policy. If anyone
have, please give your advice. At least some headup would be needed
before doing such s change, so that people that maybe don't follow
a detailed technical discussion like this one, can give their
feedback.
Yes, but I guess I can always submit a patch and people can vote on
it afterwards...
There is an alternative option I haven't previously mentioned;
simply returning values in the same way as 'bizData' is passed to
a sendPage*(), i.e. via the Flow context object. Thus (Grzegorz'
refactorings aside), the only change would be (for convenience) to
add a 'setReturnData()' JS method to call
FlowHelper.setContextObject() (Apples and JavaFlow would just use
FlowHelper) and write a very simple Action to call the flow
function. The flow-attr: module could then be used to access the
returned values in the normal way.
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.
Ellis.
