cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Blocks, Flow and Dependencies [was RE: Splitting xconf files step 2: the sitemap]
Date Mon, 10 Jan 2005 12:28:24 GMT
Reinhard Poetz wrote:

> Daniel Fagerstrom wrote:


>> 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.


>> 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

> 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 ...
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.

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?


View raw message