cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <h...@dvs1.informatik.tu-darmstadt.de>
Subject Re: XML input module (was: RE: Nice changes!)
Date Tue, 01 Oct 2002 18:16:19 GMT
On 02.Oct.2002 -- 01:32 AM, Jeff Turner wrote:
> On Tue, Oct 01, 2002 at 10:17:40AM +0200, Christian Haul wrote:

> > 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?

OK, I'm almost convined. 
 
> > 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.

OTOH this method is AFAIR only used to create a compabitility feature for
migration between the two DatabaseActions. With the original ones you 
could say values from "name*" and collapse values of parameters 
"name1", "name2", and "namesomething" to an array.

Since InputModules were available only in scratchpad sofar, shall we
remove this method and agree that all InputModules need to provide an
XPath interface? I.e. getAttribute() and getAttributeValues() accept an
XPath expression for the parameter name?

We would need to do that before 2.0.4 since I've moved them out of
scratchpad recently.

	Chris.
-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message