cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Splitting xconf files step 2: the sitemap
Date Sat, 08 Jan 2005 16:28:17 GMT
Reinhard Poetz wrote:

> Daniel Fagerstrom wrote: 


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

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



View raw message