cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: Splitting xconf files step 2: the sitemap
Date Thu, 06 Jan 2005 15:10:46 GMT
Daniel Fagerstrom wrote:
> Reinhard Poetz wrote:
> <snip/>
>> 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)
> Yes.
> 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.

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.

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

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


I think best practices will be a root sitemap without any pipeline and one block 
that is mounted at "/".

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

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

  - public components
  - pipelines
  - flowscripts (needs some more thinking how we define the interfaces but
    for me that's the even the most important service!)

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