Torsten Curdt wrote:
>
> Guys, guys, guys...
>
> > Let me state the following:
> > a) There shouldn't be two places where one can define the sitemap
> > components,
> > so it's rather the xconf or the sitemap. But having both is absolutly
> > confusing.
>
> Actually I don't think it's confusing... there are system components and
> custom components... but that's why need the cocoon-blocks soon!
I wouldn't say 'confusing' I would say 'messy', but placing components
configurations in xconf creates a number of problems and I perfectly
agree with Carsten that this is not good.
> > b) Having said a), if we decide for the xconf, it will *not* be possible
> > to define custom components in sub-sitemaps!
>
> this is fine as long as we have a custom.xconf (see the current discussion
> on blocks etc) Again:
>
> ComponentConfigurations shouldn't be in the sitemap!!
Ok, this is a good point and I agree: placing them in the sitemap
creates some concern overlap, but we moving them into the xconf creates
further problems.
See what I mean by 'disorder degrades energy'?
> > c) If we opt for defining the components in the sitemap (as it is now)
> > we help the sitemap editor in writing the pipelines as he can simply
> > see which components are available.
>
> Sorry, but you gave this argument also when talking about the parameter
> action stuff... But then let me be the devil advocat: Shouldn't we also
> put the roles into the xconf so the xconf-editor knows which roles are
> available???
Admittedly, Torsten has a good point here. There is simply too much
information around Cocoon to have it always available to your eyes.
> Come on... that's the price you have to pay for modularity... if you don't
> do it this way you will end up with one huge config file. I doubt you want
> that.
Yes, that's a good point. When we started we didn't think we could reach
this size of Cocoon.... believe me: I was not expecting this exponential
growth :)
This is why we need to move fast on the Cocoon Block side of things:
otherwise, pretty soon, Cocoon will growth too much and the
architectural foundation might collapse.
> > Hmm, currently I'm thinking of voting -1 for defining the components
> > in the xconf. This would create a deadlock. Very interesting
> > and funny thing...
>
> :) I guess we will find a sollution for this...
>
> Ok... this discussion shows it clearly: we need the cocoon-blocks ASAP!
:)
> I'm +5 for leaving everything as it is right now and concentrate on the
> blocks. Then this dicussion becomes obsolete...
Just like Carsten, I don't want to move components away from the sitemap
until we have a better solution: moving stuff in xconf doesn't help at
all if Cocoon 2.1 will be block based and we'll find ourselves having to
support components in the xconf.
> I was so glad to get the components section out of the sitemap...
don't worry, we'll do that, but not at the expense of having to support
some hybrid approach that doesn't fit our needs.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
