cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: RT: map:call as generic non-redirecting controller code
Date Wed, 04 Jul 2007 13:57:54 GMT
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:

Grzegorz Kossakowski

View raw message