You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Konstantin Piroumian <kp...@apache.org> on 2003/01/10 11:55:42 UTC
Re: Moving InputModules into the sitemap [was: [RT]: Dynamic variables in the Sitemap / Input Modules revisited]
From: "Carsten Ziegeler" <cz...@s-und-n.de>
> Hi,
>
> I really want to make a decision about the input modules, so that we can
> say: "This area is finished."
>
> Although I'm the (only?) one who thinks that the current InputModules are
> not the correct approach for use in the sitemap (as I explained often
> enough), I guess the only solution is the most pragmatic one:
>
> We simply move the definition of the current InputModules into an own
> section of the sitemap and that's it. The current implementation is
> capable of all required features but has (in my eyes) a not so appropriate
> interface. We cannot change this interface for compatibility reasons
> and defining a new interface (= new component) is not what we as
> a community want.
>
> What do you think about it?
IMO, most of the users would not like to configure input modules in the
sitemap if we provide a good enough set of preconfigured modules for
accessing request, session properties and attributes, application context
attributes and several others (i18n, xmlsource, sys-property, etc.).
What is more required (and thus more important), but probably is a little
out of context of this thread, is the syntax used to access input modules in
the sitemap. Current approach does not allow to use one value as an input to
another input module. Real life use-cases can be found in Cocoon Users list.
>
> If noone disagrees, could someone do the move? I will then remove my
> proposal from the source tree.
I am -0 for moving input modules into the sitemap, but if we agree to move
then why not call them sitemap variables? E.g.:
<map:variable name="request" src="org...RequestModule" />
Variable is a good name for JXPath-enabled input modules and they act very
similar to XSLT variables.
>
> Please, let's come to a conclusion to avoid an over-discussion of this
> topic.
> And we really need the definition in the sitemap and not the cocoon.xconf.
Those, who create or customize input modules have no problems with editing
cocoon.xconf for their needs. Having yet another component declaration in
the already overloaded sitemap is not a good idea. All IMP, of course.
--
Konstantin
>
> Carsten
>
> Carsten Ziegeler
> Open Source Group, S&N AG
>
>
> ---------------------------------------------------------------------
> 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: Moving InputModules into the sitemap [was: [RT]: Dynamic variables
in the Sitemap / Input Modules revisited]
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
> Sigh..
>
> Let's not re- and re- and re-discuss these things over and over again.
> I have the perception that (long time ago) we agreed in a lengthy discussion
> that we want to declare *all* sitemap components in the sitemap for
> visibility reasons. The user should not really know/care about cocoon.xconf.
>
> And I had the perception that we agreed (not so long ago) in a much longer
> discussion, that the input modules (for the same visibility resons) belong
> in the sitemap and not in cocoon.xconf.
>
> Am I wrong with this? Do I have a weak mind and should take a one month
> vacation in the south caribbean? (And if so, who can sponsor this...)
No need to discuss this again. Blocks will be able to plug in new Cocoon
components, and those will still need to be defined by the user. How
those components will be available is still to be decided, but IMHO all
can be made available with no further declaration.
--
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: Moving InputModules into the sitemap [was: [RT]: Dynamic variables
in the Sitemap / Input Modules revisited]
Posted by Giacomo Pati <gi...@apache.org>.
On Fri, 10 Jan 2003, Carsten Ziegeler wrote:
> Sigh..
>
> Let's not re- and re- and re-discuss these things over and over again.
> I have the perception that (long time ago) we agreed in a lengthy discussion
> that we want to declare *all* sitemap components in the sitemap for
> visibility reasons. The user should not really know/care about cocoon.xconf.
Yes, but *only* sitemap components (no ordinary Avalon components).
> And I had the perception that we agreed (not so long ago) in a much longer
> discussion, that the input modules (for the same visibility resons) belong
> in the sitemap and not in cocoon.xconf.
Well, than they should have their own section under map:components like
generators, transformers etc.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Moving InputModules into the sitemap [was: [RT]: Dynamic variables in the Sitemap / Input Modules revisited]
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sigh..
Let's not re- and re- and re-discuss these things over and over again.
I have the perception that (long time ago) we agreed in a lengthy discussion
that we want to declare *all* sitemap components in the sitemap for
visibility reasons. The user should not really know/care about cocoon.xconf.
And I had the perception that we agreed (not so long ago) in a much longer
discussion, that the input modules (for the same visibility resons) belong
in the sitemap and not in cocoon.xconf.
Am I wrong with this? Do I have a weak mind and should take a one month
vacation in the south caribbean? (And if so, who can sponsor this...)
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Moving InputModules into the sitemap [was: [RT]: Dynamic variables
in the Sitemap / Input Modules revisited]
Posted by Stephan Michels <st...@apache.org>.
On Fri, 10 Jan 2003, Carsten Ziegeler wrote:
> Stephan Michels wrote:
> > <snip>
> > We should definitely have a way to define custom input modules in the
> > sitemap, but we should better have a approach similar to Ant, having a
> > predefined set of components and using a taskdef if we need.
> > It will be terrible if I must always define all tasks in a build file,
> > which I need.
> >
> I'm not sure if I understand you correctly. Do you mean that it should
> be possible to have a predefined set in the cocoon.xconf and the
> possibility to add input modules in the sitemap?
Yes, and in my humble opinion for the other most important components too
*duck* ;-)
Stephan Michels
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Moving InputModules into the sitemap [was: [RT]: Dynamic variables in the Sitemap / Input Modules revisited]
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stephan Michels wrote:
> <snip>
> We should definitely have a way to define custom input modules in the
> sitemap, but we should better have a approach similar to Ant, having a
> predefined set of components and using a taskdef if we need.
> It will be terrible if I must always define all tasks in a build file,
> which I need.
>
I'm not sure if I understand you correctly. Do you mean that it should
be possible to have a predefined set in the cocoon.xconf and the
possibility to add input modules in the sitemap?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Moving InputModules into the sitemap [was: [RT]: Dynamic variables
in the Sitemap / Input Modules revisited]
Posted by Stephan Michels <st...@apache.org>.
On Fri, 10 Jan 2003, Konstantin Piroumian wrote:
> From: "Carsten Ziegeler" <cz...@s-und-n.de>
>
> > Hi,
> >
> > I really want to make a decision about the input modules, so that we can
> > say: "This area is finished."
> >
> > Although I'm the (only?) one who thinks that the current InputModules are
> > not the correct approach for use in the sitemap (as I explained often
> > enough), I guess the only solution is the most pragmatic one:
> >
> > We simply move the definition of the current InputModules into an own
> > section of the sitemap and that's it. The current implementation is
> > capable of all required features but has (in my eyes) a not so appropriate
> > interface. We cannot change this interface for compatibility reasons
> > and defining a new interface (= new component) is not what we as
> > a community want.
> >
> > What do you think about it?
>
> IMO, most of the users would not like to configure input modules in the
> sitemap if we provide a good enough set of preconfigured modules for
> accessing request, session properties and attributes, application context
> attributes and several others (i18n, xmlsource, sys-property, etc.).
>
> What is more required (and thus more important), but probably is a little
> out of context of this thread, is the syntax used to access input modules in
> the sitemap. Current approach does not allow to use one value as an input to
> another input module. Real life use-cases can be found in Cocoon Users list.
We should definitely have a way to define custom input modules in the
sitemap, but we should better have a approach similar to Ant, having a
predefined set of components and using a taskdef if we need.
It will be terrible if I must always define all tasks in a build file,
which I need.
My 2cents, Stephan Michels.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org