You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2002/03/14 09:17:22 UTC
[Vote]: Where to define the sitemap components?
Hi Team,
I'm still not convinced that it is a good idea to have some components
(generators, transformers etc) of the sitemap defined in the cocoon.xconf
and some in the map:components section of the sitemap.
We will confuse many users with this, believe me. There will be many
complains that for example the file generator isn't available any
more, as it is not visible in the sitemap.
So for a forthcoming release, I propose to move them back into the
sitemap and after the release we can think of a better way of defining
components.
Thoughts?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Vote]: Where to define the sitemap components?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Carsten Ziegeler" <cz...@s-und-n.de>
> Hi Team,
>
> I'm still not convinced that it is a good idea to have some components
> (generators, transformers etc) of the sitemap defined in the cocoon.xconf
> and some in the map:components section of the sitemap.
>
> We will confuse many users with this, believe me. There will be many
> complains that for example the file generator isn't available any
> more, as it is not visible in the sitemap.
>
> So for a forthcoming release, I propose to move them back into the
> sitemap and after the release we can think of a better way of defining
> components.
A solution is to *not* define components in the main sitemap at all.
Just say that the are already defined.
All the extra Components are to be defined in subsitemaps only where needed.
I think this could be a fair solution.
I'll commit the newly refactored samples ASAP, along with the new version of
POI without log4j I've just managed to do.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Vote]: Where to define the sitemap components?
Posted by Matthew Langham <ml...@s-und-n.de>.
>>
I am -1 for this. They don't belong there for SoC. As long as we are back
compatible none of the users should care. But people starting with cocoon
from scratch should get on the right track from the start.
<<
Hmm... so a site administrator defining pipelines will _have_ to look in
both the sitemap.xmap and cocoon.xconf to see which sitemap components are
available - right? Isn't this more confusing than what we have at the
moment - where the administrator just needs to look at the sitemap.xmap?
By SoC you are saying that the person who defines the available sitemap
components is different from the person who then defines the actual
pipelines. I agree that this may often be the case - therefore the argument
is valid. However not giving the sitemap author at least a hint as to which
components he can use strikes me as being a step back from what we already
have.
Now if we had a super sitemap tool that read the cocoon.xconf and the
sitemap.xmap and then presented the author with the components he can
use.... :)
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
Weblogging at: http://www.need-a-cake.com
=================================================================
-----Original Message-----
From: Torsten Curdt [mailto:tcurdt@dff.st]
Sent: Thursday, March 14, 2002 10:18 AM
To: Cocoon-Dev
Subject: Re: [Vote]: Where to define the sitemap components?
On Thu, 14 Mar 2002, Carsten Ziegeler wrote:
> Hi Team,
>
> I'm still not convinced that it is a good idea to have some components
> (generators, transformers etc) of the sitemap defined in the cocoon.xconf
> and some in the map:components section of the sitemap.
>
> We will confuse many users with this, believe me. There will be many
> complains that for example the file generator isn't available any
> more, as it is not visible in the sitemap.
>
> So for a forthcoming release, I propose to move them back into the
> sitemap and after the release we can think of a better way of defining
> components.
I am -1 for this. They don't belong there for SoC. As long as we are back
compatible none of the users should care. But people starting with cocoon
from scratch should get on the right track from the start.
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Vote]: Where to define the sitemap components?
Posted by Torsten Curdt <tc...@dff.st>.
On Thu, 14 Mar 2002, Carsten Ziegeler wrote:
> Hi Team,
>
> I'm still not convinced that it is a good idea to have some components
> (generators, transformers etc) of the sitemap defined in the cocoon.xconf
> and some in the map:components section of the sitemap.
>
> We will confuse many users with this, believe me. There will be many
> complains that for example the file generator isn't available any
> more, as it is not visible in the sitemap.
>
> So for a forthcoming release, I propose to move them back into the
> sitemap and after the release we can think of a better way of defining
> components.
I am -1 for this. They don't belong there for SoC. As long as we are back
compatible none of the users should care. But people starting with cocoon
from scratch should get on the right track from the start.
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Vote]: Where to define the sitemap components?
Posted by Stefano Mazzocchi <st...@apache.org>.
Torsten Curdt wrote:
>
> > > Sylvain Wallez wrote
> > >
> > < snip>
> > > >
> > > >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...
> > > >
> > > Does sitemap-local xconf remove the lock ?
> > >
> >
> > Hm, now it seems that we all agree on the Blocks thoughts in some way.
> > This new concept will perhaps solve all our problems.
> >
> > So why not have all sitemap components in the sitemap for 2.0.2 and
> > then start with the blocks design/implementation after the release?
>
> Well, since we are only talking about the "demo" site - I don't care. If
> you want to move them only for 2.0.2 I am fine with that - as long as we
> tackle the cocoon-blocks after the new release!!
>
> > If we now move some components, the user will get confused and have
> > to learn a new schema. And then some time later we introduce the blocks
> > and they have to learn a third one, then.
>
> ok, that's true...
>
> > Except for "it would be nice if the components are all defined in
> > the cocoon.xconf", I see really no pro for it.
>
> The pro's will only come with the cocoon-blocks...
>
> > Again, the opposite is true if you think of components defined in
> > sub-sitemaps which we all seem to agree on that this is a good think.
>
> then let's do it this way...
+1
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Vote]: Where to define the sitemap components?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> Torsten Curdt wrote:
>
> ...
>
> Well, since we are only talking about the "demo" site - I don't care. If
> you want to move them only for 2.0.2 I am fine with that - as long as we
> tackle the cocoon-blocks after the new release!!
Of course!
>...
>
> > Except for "it would be nice if the components are all defined in
> > the cocoon.xconf", I see really no pro for it.
>
> The pro's will only come with the cocoon-blocks...
>
No doubt!
> > Again, the opposite is true if you think of components defined in
> > sub-sitemaps which we all seem to agree on that this is a good think.
>
> then let's do it this way...
Puh, great!
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Vote]: Where to define the sitemap components?
Posted by Torsten Curdt <tc...@dff.st>.
> > Sylvain Wallez wrote
> >
> < snip>
> > >
> > >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...
> > >
> > Does sitemap-local xconf remove the lock ?
> >
>
> Hm, now it seems that we all agree on the Blocks thoughts in some way.
> This new concept will perhaps solve all our problems.
>
> So why not have all sitemap components in the sitemap for 2.0.2 and
> then start with the blocks design/implementation after the release?
Well, since we are only talking about the "demo" site - I don't care. If
you want to move them only for 2.0.2 I am fine with that - as long as we
tackle the cocoon-blocks after the new release!!
> If we now move some components, the user will get confused and have
> to learn a new schema. And then some time later we introduce the blocks
> and they have to learn a third one, then.
ok, that's true...
> Except for "it would be nice if the components are all defined in
> the cocoon.xconf", I see really no pro for it.
The pro's will only come with the cocoon-blocks...
> Again, the opposite is true if you think of components defined in
> sub-sitemaps which we all seem to agree on that this is a good think.
then let's do it this way...
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Vote]: Where to define the sitemap components?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> Sylvain Wallez wrote
>
< snip>
> >
> >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...
> >
> Does sitemap-local xconf remove the lock ?
>
Hm, now it seems that we all agree on the Blocks thoughts in some way.
This new concept will perhaps solve all our problems.
So why not have all sitemap components in the sitemap for 2.0.2 and
then start with the blocks design/implementation after the release?
If we now move some components, the user will get confused and have
to learn a new schema. And then some time later we introduce the blocks
and they have to learn a third one, then.
Except for "it would be nice if the components are all defined in
the cocoon.xconf", I see really no pro for it.
Again, the opposite is true if you think of components defined in
sub-sitemaps which we all seem to agree on that this is a good think.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Vote]: Where to define the sitemap components?
Posted by Torsten Curdt <tc...@dff.st>.
<snip/>
> So what about allowing <map:components> to be written <map:components
> src="sitemap.xconf"/> ?
Well, I am +0 for this one... but I guess Stefano convinced me. Shouldn't
this happen as a block configuration? Something like this:
<cocoon-block>
<sitemap src="sitemap.xmap"/>
<components src="sitemap.xconf"/>
<roles src="sitemap.roles"/>
</cocoon-block>
> This way, each [sub-]sitemap (or cocoon block) comes with a sitemap.xmap
> and an optional sitemap.xconf defininig its local components, if any.
this was already proposed in the xconf thread but IIRC it was shot down...
> The current behaviour should also be kept, for compatibility and for
> people which aren't confused by having components in the sitemap.
sure thing...
> Now the question is do we define system-wide sitemap components in
> cocoon.xconf ? If yes, they should be IMO restricted to the very minimum
> of what we're likely to find in _every_ sitemap, i.e. wildcard and
> regexp matchers, file and xsp generators, xsl transformer, xml and html
> serializers.
>
> Note also that some system-level components may make use of some sitemap
> components. Namely, the xml serializer used in some source
> implementations, IIRC.
true...
> >So, SoC or not, is the above really what we want? I think, no!
> >
> >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...
> >
> Does sitemap-local xconf remove the lock ?
it would from my side... but maybe Stefano would give a -1 then ;)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Vote]: Where to define the sitemap components?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Ok, this seems to be a very difficult task then.
>
>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.
>
I tend to agree with this. I consider cocoon.xconf to be the location
for "system" components, i.e. components that are available for _all_
components, be them related to a sitemap or not. But we may consider
some sitemap components as system-level (see below).
>
>b) Having said a), if we decide for the xconf, it will *not* be possible
> to define custom components in sub-sitemaps!
>
Definitely -1 for that. We *need* components defined locally for a
sitemap. The treeprocessor even offers more features for that than the
compiled engine, since the <map:component> is a regular component
manager configuration where you can add *any* component definition (e.g.
local jdbc datasources). However, I agree that component definition can
be considered as not being the concern of the sitemap administrator
(he/she manages the URI space, not the application configuration).
So what about allowing <map:components> to be written <map:components
src="sitemap.xconf"/> ?
This way, each [sub-]sitemap (or cocoon block) comes with a sitemap.xmap
and an optional sitemap.xconf defininig its local components, if any.
The current behaviour should also be kept, for compatibility and for
people which aren't confused by having components in the sitemap.
Now the question is do we define system-wide sitemap components in
cocoon.xconf ? If yes, they should be IMO restricted to the very minimum
of what we're likely to find in _every_ sitemap, i.e. wildcard and
regexp matchers, file and xsp generators, xsl transformer, xml and html
serializers.
Note also that some system-level components may make use of some sitemap
components. Namely, the xml serializer used in some source
implementations, IIRC.
Thoughts ?
>
>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.
>
>So, SoC or not, is the above really what we want? I think, no!
>
>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...
>
Does sitemap-local xconf remove the lock ?
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Vote]: Where to define the sitemap components?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Carsten Ziegeler" <cz...@s-und-n.de>
> Ok, this seems to be a very difficult task then.
>
> 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.
I personally think it's not so confusing, but I understand the point.
> b) Having said a), if we decide for the xconf, it will *not* be possible
> to define custom components in sub-sitemaps!
Ugh. Not nice. I would be -1 on this! We need some sub declaration system.
> 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.
>
> So, SoC or not, is the above really what we want? I think, no!
>
> 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...
Not ;-)
As always, needs never collide, only implementations do. (should I change
signature on this? ;-)
So by implementing the configuration in only sitemap.xmap or cocoon.xconf we
break some needs.
What was the need to put components in cocoon.xconf?
IIRC, it was to reduce clutter in sitemap.xmap, originally.
When the new layout of the samples is committed, there won't be much there
in every sitemap.
So this issue could be resolved, and components be declared in sitemaps.
But think of upgrade. If I upgrade some components, I need to change every
definition in every sitemap where it's declared. Not good.
But this will be resolved AFAIK with the next-to-be-defined Blocks.
So I'm +1 for taking the components away from xconf, and placing them only
in the sitemap for the time being.
This SOC issue will be resolved with Blocks.
If someone really wants to separate this in two files, he can always include
the components as external entities (XML), but I wouldn't recommend it (and
Stefano would skin me ;-).
Could this be ok?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Vote]: Where to define the sitemap components?
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Vote]: Where to define the sitemap components?
Posted by Vadim Gritsenko <va...@verizon.net>.
> 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
RE: [Vote]: Where to define the sitemap components?
Posted by Torsten Curdt <tc...@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.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Vote]: Where to define the sitemap components?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Ok, this seems to be a very difficult task then.
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.
b) Having said a), if we decide for the xconf, it will *not* be possible
to define custom components in sub-sitemaps!
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.
So, SoC or not, is the above really what we want? I think, no!
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...
Carsten
> Carsten Ziegeler wrote:
>
> Hi Team,
>
> I'm still not convinced that it is a good idea to have some components
> (generators, transformers etc) of the sitemap defined in the cocoon.xconf
> and some in the map:components section of the sitemap.
>
> We will confuse many users with this, believe me. There will be many
> complains that for example the file generator isn't available any
> more, as it is not visible in the sitemap.
>
> So for a forthcoming release, I propose to move them back into the
> sitemap and after the release we can think of a better way of defining
> components.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org