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.
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]
