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

Reply via email to