cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ellis Pritchard <>
Subject Re: RT: map:call as generic non-redirecting controller code
Date Fri, 06 Jul 2007 09:30:18 GMT

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.


View raw message