cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Michels <step...@apache.org>
Subject Re: Moving InputModules into the sitemap [was: [RT]: Dynamic variables in the Sitemap / Input Modules revisited]
Date Fri, 10 Jan 2003 11:10:06 GMT

On Fri, 10 Jan 2003, Konstantin Piroumian wrote:

> From: "Carsten Ziegeler" <cziegeler@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


Mime
View raw message