On 02.Oct.2002 -- 06:38 PM, Stefano Mazzocchi wrote:
> Quoting Jeff Turner <[EMAIL PROTECTED]>:
>
> > 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
>
Prerequisite
========================================================================
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
implementation.
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
DefaultsMetaModule.
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
http://marc.theaimsgroup.com/?l=forrest-dev&m=103338039706391&w=2
and
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103354978904793&w=2
The Votes
========================================================================
Ladies and Gentlemen, please cast your votes.
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
