cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinhard_po...@yahoo.de>
Subject Re: Splitting xconf files step 2: the sitemap
Date Sun, 09 Jan 2005 10:55:06 GMT
Daniel Fagerstrom wrote:
> Reinhard Poetz wrote:
> 
>> Daniel Fagerstrom wrote: 
> 
> 
> <snip/>
> 
>>> I would assume that a (virtual) flowscript call should be very 
>>> similar to a parametrized virtual pipeline (or maybe will they still 
>>> be called resources?). The problem is the continuation handler. I 
>>> would propose that the virtual flowscript definition must contain its 
>>> continuation handler as well, otherwise the user of the flowscript 
>>> must know block internal details about the continuation URL usage. 
>>> Are there further problems?
>>
>>
>> sorry, I haven't understood what parametrized virtual pipelines are, 
>> but I try to give you an example on what I mean: 
> 
> 
> I meant the block version of an ordinary map:resource, (i.e. a complete 
> pipeline all the way from generator to serializer or a reader) and 
> wanted to emphasize the fact that it takes parameters. I also wondered 
> if we have decided to call it pipeline instead of resource when we 
> implement VPCs, I would prefer that at least.
> 
> Now a virtual pipeline has AFAIKS very similar semantics as a 
> flowscripts from the caller POV. Booth takes the Cocoon object model and 
> parameters as input and returns a response object and resolves resources 
> relative to their block. The main difference is that the flowscript 
> creates webcontinuations that the repsonse can contain links to.
> 
>> BLOCK A
>> -------
>> - has a flowscript blockA-flow.js
>> - has an internal pipeline that makes block-flow.js accessible from 
>> other blocks
>> - flowscript (blockA-flow.js):
>>   function abc() {
>>      cocoon.sendPageAndWait("page1");
>>      cocoon.sendPageAndWait("page2");
>>      return new Customer();
>>   }
>> - sitemap:
>>   <map:flow>
>>     <map:script src="blockA-flow.js"/>
>>   </map:flow>
>>
>>   <map:match pattern="page*">
>>     ...
>>   </map:match>
>>
>>   <map:match pattern="flow.js">
>>     <map:read src="blockA-flow.js"/>
>>   </map:match>
>>
>>
>> BLOCK B
>> -------
>> - has a flowscript blockB-flow.js
>> - blockB-flow.js wants to use xyz of blockA
>> - flowscript (blockB-flow.js):
>>   function xyz() {
>>     var cust = abc();
>>     cocoon.sendPageAndWait("anotherpage", {customer:cust});
>>   }
>> - sitemap:
>>   <map:flow>
>>     <map:script src="block:/blockA/flow.js">
>>     <map:script src="blockB-flow.js"/>
>>   </map:flow>
>>
>>   <map:match pattern="anotherpage*">
>>     ...
>>   </map:match>
>>
>>
>> The problem ist, that this example wont work because when function abc 
>> sends the pipeline page1 it is resolved relative to the sitemap of 
>> blockB. 
> 
> 
> Thats also the behaviour that I would expect as a user as you imports a 
> text representation of the flowscript rather than the functions it 
> contains.
> 
>> Here we need a solution ... 
> 
> 
> I would solve this in two steps: First we need a way to use a (virtual) 
> flowscript function from a map:call. Here we can consider it as a 
> virtual pipeline as I indicated above. Given that it has been defined as 
> a VPC, it called like
> 
> <map:call function="block:blockA:abc"/>
> 
> or whatever syntax we have decided.
> 
> Next question is how we use the VPC function from a flowscript in the 
> block B. Here we must understand that the virtual flowscript function is 
> a VPC, i.e. a Java object rather than an ordinary flowscript function. 
> So in some way it must be imported (and adapted to JS function) in 
> blockB-flow.js to be used. It could either be done in some kind of 
> import statement in the script or in a special attribute in 
> map:flow/map:script.
> 
> WDYT?


Let's talk again about our needs. What I've understood so far, we want to:

  * call a flowscript function of another block *within* flowscript
  * use the return object returned by the *other* block
  * the function of the *other* block can send responses to the client
    with correctly resolved links and can create continuations

The question is, which contract we want to establish between caller and callee.

Maybe somethink like

function f_of_blockB() {
    var x = cocoon.callBlock("blockA:f_of_blockA", {a, b, c});

    // here calling a function of a sub sitemap of blockA
    var y = cocoon.callBlock("blockA:subSitemap1:f_of_blockA_subSitemap",
              {d, e});
}

can do the job ...

WDYT?

-- 
Reinhard


Mime
View raw message