Carsten Ziegeler wrote:
Sylvain Wallez wrote:
<SNIP/>
The result is that to activate/deactivate a block, you'll simply have to decomment/comment a line in the main cocoon.xconf. Example:
<cocoon>
<!-- 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"/> </cocoon>
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
directory.
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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
