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 ;)
/Daniel
