Reinhard Poetz 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:
<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>
two thoughts:
1. once on icq we chatted about implicit .xconf files to enable blocks. this goes into the same direction, doesn't it? Imean if i deploay a block inzo WEB-INF/blocks, it isn't necessary to make an explicit import.
Well, WEB-INF/blocks isn't there yet, but yes, there could be some implicit imports from deployed blocks. I finally chose an explicit <import> statement for the main cocoon.xconf rather than loading WEB-INF/*.xconf in order for this feature to work in the less magical and therefore the more predictible and understandable way.
2. how does this relate to carsten's proposal, that we are voting on?
<import> will come for free in <map:components> also. We may want to keep a uniform syntax between xconf and xmap or have a different one with <map:components src="blah.xconf"/>, which actually easily translates to an xconf with a single <import>. I have no particular preference for one syntax or the other ATM...
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
