cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject RE: [Vote]: Where to define the sitemap components?
Date Thu, 14 Mar 2002 14:45:02 GMT
> From: Torsten Curdt [mailto:tcurdt@dff.st]
> 
> 
> 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.

It's not more confusing then empty components declarations in the
sub-sitemaps. How your sitemap writer will know what components are
available? Following the logic, all the components must be redefined in
the subsitemap.


> 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 agree with this.


> > b) Having said a), if we decide for the xconf, it will *not* be
possible
> >    to define custom components in sub-sitemaps!

But it should be possible to define them in the sitmap.xconf file
accompanying sitemap.xmap.


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

Makes sense to me.


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

Good point.


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

Yup.


> I'm +5 for leaving everything as it is right now and concentrate on
the
> blocks. Then this dicussion becomes obsolete...

+-0 on moving components back, +-0 on leaving as it is, +10 for blocks.


> I was so glad to get the components section out of the sitemap...

I hear you... :)

Vadim


> --
> Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message