cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
Subject Re: XML input module (was: RE: Nice changes!)
Date Tue, 01 Oct 2002 15:32:50 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message