On Fri, 10 Jan 2003, Konstantin Piroumian wrote: > From: "Carsten Ziegeler" <[EMAIL PROTECTED]> > > > 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
