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 Mon, 03 Jan 2005 14:55:23 GMT
Reinhard Poetz wrote:

> Apart from this, let's look at what's missing to make the next step 
> towards real blocks:
> As said, a block is located in WEB-INF/blocks/[block-id]. There is one 
> central configuration file knowing how a particular block is 
> configured, which ID it has and where it is located: 
> WEB-INF/blocks/wiring.xml
> wiring.xml is used by the BlockManager to find blocks. So again, 
> what's missing?
>  1.) the BlockManager (configured by wiring.xml)


And also:
1.5.) Block protocol (which is based on the info from the BlockManager)

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

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.

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"? 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? What if I would like to 
mount a block in several places?.

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. It however 
requires that we find a way to implement the link transformer in this 

Somewhat RT I believe that the pluggable matchers in the sitemap is FS 
and do more harm than good. I'm certain that there are edge cases where 
it is usefull to plug in special pupose matchers and selectors. But the 
disadvantage is that the sitemap not is declarative in its mapping 
between URI:s and pipelines and as a consequence it is not possible to 
ask the sitemap anything about its URI space.

> 2.) and 3.) are only special cases of the new splitting mechanism 
> Sylvain introduced and the implementation should be easy. Right, or do 
> I overlook something important?

The implementation might be simple, but as indicated above there are 
some conceptual questions that I think that we have to discuss.



View raw message