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