I've been following this discussion for the last week or so and suddenly
this morning I had to start questioning exactly what the true purpose of all
this is? The idea of being able to dig out a value based on a precedence
hierarchy makes sense, but XML and XSLT already have very good mechanisms
for doing this (and Cocoon provides perfectly adequate ways of building XML
and running XSLT!). Consider, for instance:
<data>
<database>
<gunk value="foo"/>
<slime value="fee"/>
</database>
<session>
<gunk value="last time around"/>
</session>
<request>
<slime value="new value"/>
</request>
</data>
It's pretty much trivial to write a generator that would create such a
structure directly and pretty much trivial to use existing generators
(except perhaps for session data) to generate such a structure using
aggregation from the sitemap (name spaces and element names aside). It's
also easy to write XSLT that will parse such a structure and pick up a value
based on any precedence hierarchy that one might want.
I'm not really trying to discourage the creation of a similar mechanism that
is more friendly to the Java half of Cocoon, in particular since there are
performance implications to doing this via XSLT. However, it's likely
you're going to need a transform in any case and adding one more template to
traverse an XPath to a value isn't going to add that much more overhead.
Moreover, any truly powerful module configuration mechanism should likely be
XML based and that will add it's own parsing and interpretation overhead
(and perhaps be as complicated as writing an XSLT template) and of course
documentation.
I guess the I'm wondering if I wouldn't rather see development efforts go
into creating generalized generators and optimizing the existing code. It
seems to me that many times people forget about exploiting the capabilities
of XSLT and end up writing lots of unneeded Java code. Of course, this
being open source, you're completely free to ignore this suggestion, but if
you have specific reasons why doing this via XML/XSLT is problematic I'd be
interested in hearing them.
-----Original Message-----
From: Christian Haul [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 01, 2002 3:18 AM
To: [EMAIL PROTECTED]
Subject: Re: XML input module (was: RE: Nice changes!)
On 01.Oct.2002 -- 01:31 AM, Jeff Turner wrote:
> On Mon, Sep 30, 2002 at 04:56:36PM +0200, Christian Haul wrote:
> > On 30.Sep.2002 -- 09:59 PM, Jeff Turner wrote:
> > > On Mon, Sep 30, 2002 at 01:19:04PM +0200, Christian Haul wrote:
> > > > I would prefer that module to be a "meta" module that can be
> > > > configured to take input from any source (i.e. another InputModule)
> > > > rather than do the reading itself.
> > >
> > > >From what I gather, Meta modules take in as input, a) another module,
b)
> > > a configuration. In this scenario, what object would we feed JXPath?
> > > Where does the DOM come from?
> >
> > As already pointed out in others' replies, jxpath can operate on more
> > than DOM, i.e. uses reflexion to obtain the get and set methods.
> ....
> > > This might already be possible, since I think JXPath can traverse from
> > > the Session object to a DOM.
> >
> > Yes. The current request InputModule uses jxpath and allows this
> > functionality. However, I believe this is a feature that deserves to
> > be universally plugable.
>
> It is universally pluggable, only the plugin mechanism is inheritance,
> not composition. The current model is:
>
> AbstractJXPathModule .
> |---- RequestModule
> |---- SessionModule
> |---- XMLModule
> +---- ....
>
> Where each subclass just chooses what Object to let JXPath use.
>
> If I've understood you, you're proposing to change from inheritance to
> composition. Create a JXPathModule that takes as 'input', *any* other
> module:
>
> <component-instance name="jxpath" class="...JXPathModule">
> <input-module name="SessionModule"/>
> </component-instance>
Right.
>
> The JXPath module then provides XPath access to the input-module's....
> what? This is my question above. A Module's public interface doesn't
> allow access to the raw object model that JXPath needs. It's always
> pre-digested, accessible through tokens that the Module defines. For
> instance, how would the above XML snippet translate to code? How could
> XMLModule functionality be achieved?
The degree, to what they digest the data is not set to
stone. SessionModule could, for instance, just return the session
object.
If we believe that jxpath is the one and only interface that the
InputModules should expose, I'm fine with that. Then it would make
perfectly sense to make all of them inherit from
AbstractJXPathModule. Obviously, all complex ones do currently.
But what about the others. How will they fit in e.g. DateMetaInput
(parses a string and returns a java.util.Date)? Granted, the simple
ones like NullInput (always returns "null") won't need it.
Another point may be that when switching to jxpath, would that impact
the interface? Does getAttributeNames() still return a reasonable
enumeration?
> IMHO, inheritance is the way to go, with more advanced "chaining"
> functionality layered underneath, so that any subclass can automatically
> be chained.
Any automatic lookup or chaining should at least be configurable. Like
extending the DefaultsMetaModule.c
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
