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.
+1
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
jxtg.
The fact is that blocks.properties 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.
/Daniel
