cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <>
Subject Re: XML input module (was: RE: Nice changes!)
Date Mon, 30 Sep 2002 14:56:36 GMT
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.

> I was thinking it's the other way round; DefaultMetaModule needs
> generalizing, in order to be able to 'default' arbitrary input modules,
> including XMLModule. Currently, it can only 'default' those with keys
> expressible as XML element names. That's what the proposed syntax below
> achieves.

Right, it's actually only a proof-of-concept module, more advanced
mechanics are imagninable and - it appears - desirable.

> > or document stored as session attribute.
> 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.

> > > Regarding the caching of sources, it is definitely needed. Maybe XSP
> > > processing part will provide some hints on how to implement it correctly in
> > > Cocoon's way.
> > 
> > Wich would then become the task of the module that is used to obtain
> > the data. For a session attribute it would not be needed, for example.
> Hmm.. thinking at a tangent...
> Often, one wants a variable's value to come from one of a number of
> sources, ordered by preference:
>  - From a request value, or if not present,
>  - From a session value, or if not present,
>  - From an XML config file or database.

To this I would suggest to have a module that does exactly this, along
the lines of the current DefaultsMetaModule. Just that it takes a
configurable list of modules to test. I hope that it's still not FS ;-)

> This is the situation in Forrest; we want to specify a skin in an XML
> config file, but allow it to be overridden for a user's session, and
> optionally overridden by a request param.
> Perhaps the idea of "meta" modules can be generalized to that of
> "chained" modules? Each module type just worries about resolving what it
> knows about, and lets some underlying machinery do the defaulting to
> whatever's next in the chain.

Yes. That's the idea of the prototype DefaultsMetaModule. Just that it
stops with one alternative.

C h r i s t i a n       H a u l
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

To unsubscribe, e-mail:
For additional commands, email:

View raw message