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]
