cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Splitting cocoon.xconf (was Re: Cocoon, a Huge, Scary Beast?)
Date Mon, 20 Dec 2004 15:02:51 GMT
Stefano Mazzocchi wrote:

> Sylvain Wallez wrote:


<snip/>

>> After doing some internal support on our projects here last week, I 
>> saw once again how difficult it is for people, even experienced ones, 
>> to strip down Cocoon to their needs.
>>
>> The problem is that you have to know beforehand what blocks we want 
>> to use, compile them and -- here comes the real problem -- generate a 
>> cocoon.xconf. If you ever want to add or remove a block later on, you 
>> have to strip down the project's cocoon.xconf or merge it with the 
>> one that resulted from a new build with more blocks.
>>
>> Sooo complicated and painful when there are so many components you 
>> don't even know what their use is. Result: all blocks are included in 
>> every project, which effectively makes Cocoon scary (not talking also 
>> of the slow startup).
>>
>> So, enough is enough, I started this week-end to scracth something 
>> that has been itching me for long: being able to have one xconf 
>> snippet per block (including the core block), the main cocoon.xconf 
>> being just a set of imports of block-specific xconf snippets.
>>
>> 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, but that 
>> some selectors can be fed by multiple blocks (e.g. source protocols 
>> provided by core, xmldb and databases blocks or taglibs provided by 
>> taglib and faces blocks).
>>
>> So I started refactoring ECM++ so that a selector doesn't manage 
>> components itself but adds them to its service manager, and also 
>> delegates select() to this manager. This actually "flattens" the 
>> component space, thus allowing variations of a given role (what 
>> normally goes into selectors) to come from different sources. This is 
>> nearly done (still some problems for selectors nested in selectors), 
>> and <import> should come soon after.
>>
>> WDYT?
>
>
> AWESOME!!! You are my new hero :-) [well, you are in my hero list 
> already but your plaque was getting rusty now I'm off to shine it up 
> again ;-)]


Kewl, but please wait for it to actually work before shining my plaque ;-)

Sylvai

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Mime
View raw message