cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <>
Subject [VOTE] Input module chaining (Re: XML input module)
Date Fri, 04 Oct 2002 09:07:55 GMT
On 02.Oct.2002 -- 06:38 PM, Stefano Mazzocchi wrote:
> Quoting Jeff Turner <>:
> > 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

The code base now contains for some time so called InputModules
(together with their OutputModule and some database autoincrement
module friends) as an abstract, uniform method to access small data
items. Examples are request attributes, request parameters, session
attributes &c. 

With this other components can be created to be independent of the
data source, thus reducing the the number of components that share
functionality but differ with respect to data sources to one

Since the interface is simple, consisting only of getAttribute(),
getAttributeValues(), and getAttributeNames(), it is trivial for a
user to implement custom InputModules and combine them with existing
functionality or vice versa.

Some InputModules provide simple transformation / interpretation of
data obtained from other InputMoudles -- effectively chaining
modules. Since they are composed of other modules, I like to call them
"meta" modules. This is done without change to the original
interface. Examples are the DigestMetaModule or the

InputModules are currently used: sitemap (treeprocessor in 2.1,
compiled in 2.0): "{request-param:foo}", modular.Database*Action,
modular.WildcardMatcher, modular.CachingWildcardMatcher, flow

The Case
Now, since important objects like the request object offer many kinds
of data, Konstantin came up with a JXPath based InputModule for the
request object, simplifying things even further, because no separate
modules are needed for request parameters, attributes, headers, &c.

Jeff provided a patch for a JXPath based module that operates on
XML. This lead to a discussion 

a) if JXPath should be 
a1) a meta module or 
a2) property of specific modules.

b) how chaining should be done
b1) as property of individual modules (i.e. through inheritance)
b2) as meta module (i.e. through composition)

c) the method getAttributeNames()
c1) is superfluous and should be removed
c2) is useful and should stay

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

The State Of The Discussion
For a) we settled on a2) since otherwise we would need a way to pass
the request object to the next module which would not fit into the
current interface. Besides, JXPath may not be useful for each and
every module.

For c) we settled on c2) with a lose contract, i.e. it's not always
guaranteed to return an enumeration that contains all possible
attribute names. This is mostly because it would be difficult to
enumerate all XPaths expressions.

For d) we agree on d1)

For b) we still have a dispute. Jeff believes this is easily
achievable through inheritance and would make sense for every module
to obtain values from other modules if the attriibute is absent. I
believe that this is a completely different concern and should be
handled with a meta module that combines several other modules and
e.g. uses the first attribute present. In addition, I feel that this
way it would be easier to code new custom modules.

Please see original thread for arguments in detail

The Votes
Ladies and Gentlemen, please cast your votes.

C h r i s t i a n       H a u l
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

To unsubscribe, e-mail:
For additional commands, email:

View raw message