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.
Both FlowScript and JavaFlow don't have a problem with this, it won't
break anything, but Apples has both an Interpreter implementation
(ApplesProcessor) and its own AppleController interface, which is also
returning a void. This is more of a problem since this is a 'hard' void
rather than the 'soft' void via ScriptRuntime.call() and
Method.invoke(): without breaking all Apples, the only way to implement
this would be to use the AppleResponse object to set a return value, in
much the same way as it is used to set the redirect etc. A little
refactoring of ApplesProcessor then needs to pass back this value.
Seem OK to me. But don't know much about Apples.
However....
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();
}
/Daniel
