Re: Splitting xconf files step 2: the sitemap

[Reinhard Poetz]

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