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.
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 ScriptRuntime.call() 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.
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.
So revolution or evolution?
Ellis.
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: http://thread.gmane.org/
gmane.text.xml.cocoon.devel/73700
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
