cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [2.2] Readd jx or move template block to core
Date Tue, 30 Aug 2005 09:03:14 GMT
Carsten Ziegeler wrote:

>Upayavira wrote:
>>Daniel Fagerstrom wrote:
>>>>Or do we want to move all samples to the block?
>>>To the core-samples block that depends on JXTG.
>>That's exactly the idea. After all, we want to be able to have a core 
>>that excludes samples. Easiest way to achieve that is to have the 
>>samples in an excludable block.
>Hmm, moving samples into an own block is one thing (which I think we
>should really do), but for me it seems a little bit strange to have a
>Cocoon core, a Cocoon core samples block and an additional jxtg block
>while the cocoon core samples blocks depends on an additional one.
The core of today is large and monolithic and mixes basic framework 
infrastructure with application components. IMO we should move out as 
much as possible from the core so that it consist of the tree 
interpreter, component handling, basic interfaces and components that 
are needed to implement the framework. The rest should go to blocks.

I think it is necessary to make the core small and focused, today there 
are at most a handfull of Cocoon long timers that know enough about 
whats going on in the internals of Cocoon to dare to work with it. For a 
new commer it would require such a huge amount of work to understand the 
internals that I wonder if it will happen.

Now, if we have a core that only is about basic framework core samples 
stops to make sense. Taking a look at todays core samples I wonder if 
they even make sense today, do they reflect what we want to show as 
"recomended" basic Cocoon usage?

What IMO would be much more usefull (although I not volonter to do 
anything about it ;) ) would be to decide what is basic Cocoon 
functionality: core, template, cforms and maybe some other stuff, and 
find some term for it, core blocks or basic blocks or something else. 
Then we could skip the core samples and have some much more illustrative 
"basic Cocoon" samples.

>Like Vadim suggest, perhaps we can rewrite some of the samples and clean
>up the dependencies.
>However, if you currently exclude all blocks, then the samples do not
>work which is imho really bad
Seem like a technical question that we could solve in better ways than 
putting everything in core or using xslt as template language instead of 

The fact is that sucks badly, we need a build system 
that take block dependencies into account. When we could add whatever 
dependencies needed for the "basic Cocoon sample block" and then you 
just need to say that you want to build that.


View raw message