cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Splitting cocoon.xconf (was Re: Cocoon, a Huge, Scary Beast?)
Date Tue, 21 Dec 2004 07:51:52 GMT
Carsten Ziegeler wrote:

>Sylvain Wallez wrote:
>>The result is that to activate/deactivate a block, you'll 
>>simply have to decomment/comment a line in the main 
>>cocoon.xconf. Example:
>>  <!-- block-specific components -->
>>  <import src="cocoon-pdf-block.xconf"/>
>>  <import src="cocoon-portal-block.xconf"/>
>>  <import src="cocoon-svg-block.xconf"/>
>>  <!-- the core cocoon components (parser, cache, pipelines, etc) -->
>>  <import src="cocoon-core.xconf"/>
>>The biggest problem is not related to the actual inclusion, 
>Yes, the inclusion could be done by using entities although the explicit
>import statement looks nicer to be.
>I like the idea, but I would love to extend it a little bit:
><import src="configs/*.xconf"/>
>This would import all files ending with ".xconf" from the configs directory.
>So a little support for patterns would be great. An alternative would be:
><import dir="configs"/> which simply imports all files in the configs

This is a good compromise between automagically loading all *.xconf (see 
my previous answer to Reinhard) and having to explicitely declare all 
imports one by one.

However, that will work only if Cocoon doesn't run in an unexpanded war 
file. But that should not be a real problem as most deployments are 
using expanded wars, and we can provide some meaningful error messages 
if ever the situation arises.

So, let's implement the basic <import> first and add little sweeties 
afterwards ;-)


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message