On Tue, Oct 01, 2002 at 10:17:40AM +0200, Christian Haul wrote:
> On 01.Oct.2002 -- 01:31 AM, Jeff Turner wrote:
...
> > 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.
Yes, it would have to, to accommodate the most general 'upstream' module,
JXPath. but then you've got such a loose contract between modules as to
be almost useless:
public interface InputModule {
Object getData();
}
At least with the current module (attributes and values), we can have
modules like DefaultsMetaModule which can default *any* 'upstream'
module's values.
> 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)?
However it currently works. Putting the question the other way, what sort
of inter-module data model is sufficiently general to allow JXPath on one
hand, and DateMetaModule on the other?
> 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?
Hmm, probably not. It wouldn't make much sense to iterate through all
possible XPaths.
--Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
