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:47:42 GMT
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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message