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! > 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!! > 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??? 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. > 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... I was so glad to get the components section out of the sitemap... -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
