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 Thu, 06 Jan 2005 18:07:48 GMT
Reinhard Poetz wrote:

> Daniel Fagerstrom wrote: 


>>>  2.) ECM has to "ask" the BlockManager which blocks exist and 
>>> include all block
>>>      specific component declarations:
>>>      /WEB-INF/blocks/4711/block.xconf
>>>      /WEB-INF/blocks/4712/block.xconf
>>>      ...
>> This is natural to do based on the current "global" block component 
>> handling in Cocoon, where all block components are included in the 
>> global cocoon.xconf. The question is if we should continue in this 
>> way or not. An alternative way would be to only include components in 
>> the sitemap where it is used (and of course its subsitemaps). In that 
>> case the block.xconf can be found by using a "block config" protocol: 
>> "blockconfig:my-block" e.g. and included in the sitemap where the 
>> block is used using Sylvain's include mechanism.
>> Avoiding having globaly defined components as default might be an 
>> advantage as it decreases the risk that blocks collide on the other 
>> hand it might make it somewhat more complicated to use blocks as one 
>> have to decide where to include their components. I don't know, but 
>> now with the more flexible component configuration mechanism we at 
>> least have a choice.
> Sylvain and I had a discussion about this as well. Our conclusion was 
> that the block.xconf contains markers whether a component is global or 
> lokal. 

Makes sense to make it choosable, wouldn't it be even better to make it 
part of the deployment descriptor?

>> If we don't include block components at root level as default, the 
>> ECM doesn't have to ask anything.
>>>  3.) the sitemap processor "asks" the BlockManager where the 
>>> root-sitemaps of
>>>      all blocks can be found (configured in the block.xml - the main
>>>      configuration file of a block)
>>>      /WEB-INF/blocks/4711/sitemap.xmap
>>>      /WEB-INF/blocks/4712/myblocksitemap.xmap
>> Here we have a similar question: global mount at the root level or 
>> explicit where it is used.
>> We could mount block sitemaps using the "map:mount" construction 
>> togeher with the block protocol. An advantage with this is that it is 
>> a natural extension on what we already have, no need for any new 
>> concepts. A disadvantage is that it is far from obvious how to 
>> implement the link transformer that transforms from the block 
>> protocol to links.
> Another disadvantage: I want to deploy a block and this deployment 
> shouldn't require a change in the root sitemap. 

>> If we instead mount blocks at the root sitemap level, which is the 
>> current plan if I understand 
>> 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.

>> 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? 
> before
> I think best practices will be a root sitemap without any pipeline and 
> one block that is mounted at "/". 

Sounds also reasonable. The sitemap mounting is part of deployment 
rather than block.xml I hope, so that blocks from different places not 
are going to kill each other.

>> What if I would like to mount a block in several places?.
> No concept for this but I'm not sure wheter we will really need it. 

I realized after I wrote the post that it probably don't make any sense 
for other people.

I have developed a way to use "polymorphic" sitemaps, that we make good 
use of in our webapps to reuse and extend common functionality. It 
doesn't require any extensions to Cocoon so I have forgoten to write 
about it. But it takes more than enough time to respond to my current 
RT, so I will not say anything more right now ;)

>> Part of the problem is that the sitemap is "non-declarative" in the 
>> sense that all matchers must be executed in order untill one matches 
>> before you know if a sitemap respond to a certain URL. While the 
>> BlockWiring mount is a little bit more declarative so that you can 
>> have a bidirectional mapping between the block protocol and 
>> "external" URLs. I think that it will confuse users to use both 
>> "declarative" and "procedural" mounts in the same application.
>> Personally I think that I prefer mounting both components and 
>> sitemaps from blocks in the application sitemaps that use them. 
> For me the strengh of the blocks concept is isolation. I deploy a 
> block into my application and get a set of "services" that can be used: 

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 

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



View raw message