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 Sat, 08 Jan 2005 14:14:35 GMT
Daniel Fagerstrom wrote:
> Reinhard Poetz wrote:
> 
>> Daniel Fagerstrom wrote: 

<snip/>

>>> If we instead mount blocks at the root sitemap level, which is the 
>>> current plan if I understand 
>>> http://wiki.apache.org/cocoon/BlocksWiring right, we get some 
>>> advantages: The link transformer will be easier to implement, maybe 
>>> it will be easier to use a block sitemap as you don't need to write a 
>>> sitemap rule. But there are a number of questions about what it will 
>>> mean to mount a block at the root level. What will happen if one 
>>> block is mounted at "/foo" and one at "/foo/bar"? 
>>
>>
>> First the list of all mounted block sitemaps is gone through. The 
>> mount uri that fits best is called. 
> 
> 
> Best match semantics is IMO good as you can see in my RT.

It's the only chance here because when you deploy a block you can't influence 
the order when a block is mounted.

> 
>>> How should it be related to the rules in the root sitemap, are the 
>>> mounts in the wireing used before or after the root sitemap? 

<snip/>

> I agree that the strengh is isolation. The reson for me to talk about 
> locality is the case when you have a large webapp. The sub sitemaps can 
> act as subapplications, and you might want to have them isolated from 
> each other using different set of blocks. But I don't know if it is 
> worthwhile.
> 
>>  - public components
>>  - pipelines
>>  - flowscripts (needs some more thinking how we define the interfaces but
>>    for me that's the even the most important service!)
> 
> 
> 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:

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.

Here we need a solution ...

-- 
Reinhard

Mime
View raw message