Return-Path: 
 <cocoon-dev-return-31612-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 82873 invoked by uid 500); 7 Oct 2002 08:05:56 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 82851 invoked from network); 7 Oct 2002 08:05:55 -0000
Message-ID: <B6352CB87AA70442A1C6F49E6B658C9875BFB2@postman.flagship.ru>
From: Piroumian Konstantin <KPiroumian@protek.com>
To: "'cocoon-dev@xml.apache.org'" <cocoon-dev@xml.apache.org>
Subject: RE: [VOTE] Input module chaining (Re: XML input module)
Date: Mon, 7 Oct 2002 12:06:20 +0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

> From: Christian Haul [mailto:haul@dvs1.informatik.tu-darmstadt.de] 
> On 04.Oct.2002 -- 11:07 AM, Christian Haul wrote:
> > On 02.Oct.2002 -- 06:38 PM, Stefano Mazzocchi wrote:
> > > Quoting Jeff Turner <jefft@apache.org>:
> > > 
> > > > Ehm.. more code, less talk :)
> > > 
> > > Before you guys start coding something that looks like FS from 10 
> > > Km, please,
> > > make a formal votation by writing a small description of 
> what you are trying to 
> > > do. TIA
> 
> > a) if JXPath should be
> > a1) a meta module or 
> +0
> > a2) property of specific modules.
> +1

If "property of specific modules" means inheritance from the
AbstractJXPathModule then +1 of course a2). Having general purpose
JXPathMetaModule will require more verbose declarations in cocoon.xconf
where every other module should be declared as an input to JXPath meta
module. Inheritance is better, IMO.

> 
> > b) how chaining should be done
> > b1) as property of individual modules (i.e. through inheritance)
> -1 (modules may do so)
> > b2) as meta module (i.e. through composition)
> +1 (preferred method)
> 
> > c) the method getAttributeNames()
> > c1) is superfluous and should be removed
> -1

One -1 is enough, but here is the second -1.

> > c2) is useful and should stay
> +1

+1 
implement it were possible and return null or throw an exception (?) in the
other case.

> 
> > d) when chaining modules, should it be possible to augment 
> / replace 
> > the attribute name.
> > d1) yes
> +1

+1 of course.
The proposed syntax is similar to the Ant's <mapper> element's. What if we
use Cocoon-style matcher syntax? E.g.:
<attribute-mapping from="*" to="/skinconf/{1}"/>

?

> > d2) no
> -1

-1

--
  Konstantin  

> 
> 	Chris.
> -- 
> C h r i s t i a n       H a u l
> haul@informatik.tu-darmstadt.de
>     fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08
> 
> ---------------------------------------------------------------------
> 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