cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: Splitting xconf files step 2: the sitemap
Date Mon, 03 Jan 2005 09:47:48 GMT
Sylvain Wallez wrote:
> Hi team,
> 
> I finished step 2 of the include feature: it is now fully operational in 
> the sitemap in the same way as in xconf files. The sitemap-specific 
> configuration attributes such as "label", "mime-type" and 
> "pipeline-hint" are taken into account on sitemap components wherever 
> they are declared, even in the main cocoon.xconf (see 
> CocoonServiceManager and ProcessorComponentInfo for more details).
> 
> Step 3 will allow for a flat fortress-style configuration (the current 
> style will of course still be available).
> 
> Now comes a question: each block defining sitemap components will 
> provide a [block-name]-sitemap.xconf, but where should we include it? So 
> far, I see the following alternatives for inclusion, but don't know 
> which one to choose:
> 1 - include it in the main cocoon.xconf (this is possible as xconf files 
> and <map:components> are totally equivalent)
> 2 - include it in the root sitemap.xmap, similarily to what I did for 
> cocoon.xconf
> 3 - include it in the block-specific sitemap. That makes the smallest 
> root sitemap yet still allows to easily add block-specific components to 
> any sitemap as [block-name]-sitemap.xconf can be located in 
> context://WEB-INF/xconf
> 
> Thoughts?
> 
> Enjoy and happy new year to you all!

Happy new year to you too!


Currently we don't have block-specific sitemaps and the usecase for splitting a 
sitemap is the huge root sitemap with many sitemap components that makes 
understanding what's going on very complex. I agree with Stefano that we don't 
need any automagic here. An include works best IMO.

Let's look at blocks:
A block is located at WEB-INF/blocks/[block-id] and has a root sitemap for this 
block. Where this root sitemap can be found is declared in the block descriptor.

If the block developer wants to split this root sitemap, he should do it 
explicitly. (BTW, I think we don't even need to support any protocols here 
because pointing to somewhere outside of the block would break its isolation).

                                     - o -

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

  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

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?

-- 
Reinhard


Mime
View raw message