cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: Splitting xconf files step 2: the sitemap
Date Sun, 02 Jan 2005 18:30:59 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? 

I prefer option 3 as it means (at least I think it means) components 
will only be defined if they are actually accessed.  In effect, this 
means you could deploy Cocoon with all its blocks with little to know 
overhead.  IMO, this is also one case where it might be "OK" to 
"automagically" load the xconf file that is in the same directory as the 
sitemap (perhaps only if one isn't specifically included).

Ralph


Mime
View raw message