cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Splitting cocoon.xconf (was Re: Cocoon, a Huge, Scary Beast?)
Date Mon, 20 Dec 2004 14:25:54 GMT
Sylvain Wallez wrote:
> Marc Portier wrote:
> 
>>
>>
>> Reinhard Poetz wrote:
>>
>>> Tony Collen wrote:
>>>
>>>
>>> as said in my previos mail: we *have to* reach a common understanding 
>>> on what Cocoon *core* is.
>>>
>>
>> it seems logic to me there would be something as 'minimal' and 
>> 'typical' as opposed to the current 'full'
>>
>> More categories would probably be just a waste of energy?
>>
>> And yeah, I sense somewhat your fear for some long-winding discussion 
>> on the outer-boundaries of those (including room for quite some 
>> surmising mails eloquently brought as the new testament)...
>>
>> Now, being really pragmatic, and somewhat inline with Daniel's 
>> suggestion of moving out the blocks on the svn-repo (sounded quite 
>> ok), there seems to be an easy win based on the build-system we 
>> already have
>>
>> - provide sample local.*.properties files for the various categories
>> - opt for one of those to become the default one (I guess deciding 
>> will depend on what is actually in those, or else content discussions 
>> will be fueled by this upfront decission)
>>
>> all of which should at least ensure:
>>
>> - that new blocks added do _not_ get automatically added to the build?
> 
> 
> 
> 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 ;-)]

-- 
Stefano.


Mime
View raw message