cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: Blocks, Flow and Dependencies [was RE: Splitting xconf files step 2: the sitemap]
Date Mon, 10 Jan 2005 10:35:44 GMT
Daniel Fagerstrom wrote:
> Reinhard Poetz wrote:
> <snip/>
> 
>> I think of composing an application out of flow calls:
>>
>> function myF() {
>>
>>    var newAccount = [here call a flow function of another block]
>>                      e.g. cocoon.blocks.blockB.createNewAccount();
>>    if(newAccount.type == "xyz") {
>>      cocoon.sendPage("xyz");
>>    }
>>    else {
>>       cocoon.sendPage("abc");
>>    }
>> }
>>
>>
>> So calling another block has to return a Java(script) object (a stream 
>> of SAX
>> events doesn't help here!) and I don't want to care which flowscript 
>> files have
>> to be loaded to make my call work.
>>
>> If we go this way we have to solve the problem that the flowscript of 
>> the other
>> block runs completly isoluated from the calling the block.
> 
> 
> I think that is the way to go.
> 
> The important thing IMO is that when we use a flowscript today, it has 
> access to a global context in terms of the cocoon object. When we 
> introduce blocks each block must have a own cocoon object. This block 
> local cocoon object has access to global stuff as before but also to 
> such things that are internal to the block. Also all relative URIs must 
> be resolved by relative the block rather than relative the user. There 
> might be internal pipelines that the block resolver has access to but 
> that not are exported.
> 
> This means that we cannot consider the exported flow calls as normal 
> java script functions anymore, they are more like methods that are 
> invoked at a certain object. And the syntax:
> 
>  cocoon.blocks.blockB.createNewAccount();
> 
> illustrates that interpretation in a nice way.
> 
> 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).


>> This has the
>> advantage that we don't have to work around the missing namespace 
>> concept of
>> Javascript but has the disadvantage that we have to find a way that in 
>> the other
>> block (runs isolated from the first block) continuations are created 
>> and that we
>> have to return the result of this function to the calling block.
>>
>> I fear that this isn't possible ...
> 
> 
> 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 ...

-- 
Reinhard

Mime
View raw message