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 }
