Vadim Gritsenko skrev:
Daniel Fagerstrom wrote:
Vadim Gritsenko skrev:
Daniel Fagerstrom wrote:
I would much prefer to just use the return value of the flowscript:
myFlowAction() {
return calculateSomething();
}
I don't think this will work with FOM_Cocoon.suicide()
That was a cryptic message ;) I need some more details to see what is
the problem.
Sorry :)
To give some context: we are not discussing any changes in how you use
flowscripts. What we discuss is adding an action that reuses the flow
infrastructure. This is for making it easier to write stateless webapps.
...
Does the problem you see still apply in the "flow action" scenario?
Yes; here is minimal example of the situation [1]:
<map:act function="foo">
<map:generate src="{one}"/>
<map:transform src="{two}"/>
<map:serialize/>
</map:act>
function foo() {
bar();
}
function bar() {
baz();
}
function baz() {
// This will work:
cocoon.result = { one: "one.xml", two: "two.xslt" };
FOM_Cocoon.suicide();
// This does not, without refactoring all of the methods above :)
return { one: "one.xml", two: "two.xslt" };
}
I think I understand. I haven't used flowscripts in such a low level
way. Where is the cocoon.result mechanism implemented?
If you have non trivial amount of javascript already written, it won't
be possible to use new flowscript actions stuff if they do not work with
suicide() method.
I guess that the flow action could look for the cocoon.result value in
cases where there is no return value from the function. Don't know how
to deal with the, FOM_Cocoon.suicide(). Does it have to be dealt with?
Doesn't it just work as a break command?
Any suggestion about how to deal with it?
/Daniel