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.
|