cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Splitting cocoon.xconf (was Re: Cocoon, a Huge, Scary Beast?)
Date Mon, 20 Dec 2004 11:23:08 GMT
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:
  <!-- 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"/>

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.



Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message