Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
<snip/>
A question here is what flowscript functions that should be exported from a block. I would prefer to explictly enumerate the functions and possibly whole scripts that are exported rather than exporting everything in the map:flow sections.
Maybe we can work with an attribute in the script declaration:
<map:script src="public-flowscript.js" public="true"/>
(Don't know if this is technically possible because this requires that when we call a function from we must know where it is defined).
Or maybe more explicit:
<map:script src="public-flowscript.js" public="fun1 fun2 fun3"/>
Then it is explicit what is exported and it is also easy for the framework to find the functions that should be usable from outside.
<snip/>
Can you expand on why you fear that it is impossible. Concerning web continuations I would assume that the normal case is that they are local to the block that creates them and handled by rules in the blocks sitemap, and that links are handled with the block link rewriting mechanism. Then it is the block writers choice to put the continuation handling sitemap rule in the external or the internal pipeline.
Concering objects that are returned from a block flowscript function I wouldn't don't see any problem (yet ;) ) it is an ordinary Java class, possibly from some Rhino name space.
True, but this Java object has to be "put into" the calling script at the right place. So you have to freeze the calling script, call the flowscript function of the block, this flowscript can produce continuations and when this function is finished, the calling flowscript has to resume at the right place using the result object of the block flowscript.
... that's the reason why I'm a bit worried
Maybe I'm missing something, but a function call always implictly creates a continuation. The function call can be seen as: create a continuation, save it as a special place in the execution stack, goto the first instruction in called function, execute the instructions in the function. Then the return means: fetch the saved continuation in the execution stack and call it.
Update after reading it again: Maybe we have to create two continuations ...
function f_blockA() {
var x = cocoon.blocks.blockB.createNewAccount(); // create continuation 1
}
---
function createNewAccount() { cocoon.sendPageAndWait("xyz"); cocoon.sendPageAndWait("abc"); return new Customer(); }
When createNewAccount() returns the Customer object, "continuation 1" is resumed and the return object is assigned to variable x.
... again, don't have a clue if this works ...
The explicitly created continuations, gives you a way to "return" to positions in the program execution other than the position after a function call.
So I'm not getting why we should need to create the continuation1 and resuming it for simulating function call semantics. This is what the function call does by it self. Or are there other mechanisms involved that I'm missing?
A somewhat unrelated thing that we have to think about is the web continuations created in the block, do we need to shield the web continuations created in the block or not?
/Daniel
