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 Thu, 05 Jul 2007 17:10:22 GMT

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.

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.


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.

So revolution or evolution?


On 4 Jul 2007, at 14:57, Grzegorz Kossakowski wrote:

> Daniel Fagerstrom pisze:
>> Ellis Pritchard skrev:
>>> Hi,
>>> Yes, looking at that thread makes the decision look at best  
>>> arbitrary, at worst spiteful for those who were doing something  
>>> quite elegant with the former behaviour!
>>> But it's actually not so bad for the 'facists' out there (see the  
>>> thread for why I use this term!!):
>> During a period Cocoon grow explosively, so I think the community  
>> tried to keep some control over the basic contracts. The bad part  
>> was that the community during a period was a little bit to keen to  
>> forbid things. But that attitude disappeared after a while.
>>> It is the CallFunctionNode which enforces the contract of  
>>> redirection, not any higher level flow construct; therefore we  
>>> *could* leave that contract alone, and instead implement this  
>>> functionality (ironically) with an Action, which then defines  
>>> exactly the semantics as discussed (or, if actions are really to  
>>> be frowned upon, an entirely new type of sitemap node).
>> Actions would be OK, (so would IMO modifying the use of call as  
>> well, but that would require a new vote I guess).
>>> So at the minimum we'd only need to:
>>> a) change the Interpreter API to allow a function to return a value.
>> I think that Interpreter is part of our "official" API, so we must  
>> consider back compatibility and our deprecation policy. Does  
>> changing the return value from void to Object create back  
>> incompatibility? If it does the simplest way is probably to add a  
>> new method that has a return value, and possibly deprecating the  
>> current one. Also one have to keep in mind that javaflow and  
>> apples depends on the flow API.
>>> b) write an Action to allow calling the function and returning  
>>> the value to the nested sitemap.
>> Sound good. Your suggestions would IMO be a great addition to  
>> Cocoon which would simplify usage and learning curve. Patches  
>> would be welcome ;)
> +1 for all the above. Ellis, if you are going to implement what you  
> proposed it would be helpful to discuss returning and passing  
> values from flowscript. I do not know if you have been reading  
> discussion about planned modifications to Object Model handling. I  
> suggest to read that thread because my modifications are going to  
> affect your work, see: 
> gmane.text.xml.cocoon.devel/73700
> -- 
> Grzegorz Kossakowski

View raw message