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 Thu, 05 Jul 2007 21:33:45 GMT
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 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();

I would much prefer to just use the return value of the flowscript:

myFlowAction() {
   return calculateSomething();


View raw message