On 14.Mar.2003 -- 02:19 AM, Jeff Turner wrote:
> On Thu, Mar 13, 2003 at 03:54:21PM +0100, Christian Haul wrote:
> > On 14.Mar.2003 -- 01:26 AM, Jeff Turner wrote:
> > > On Thu, Mar 13, 2003 at 01:44:37PM +0100, Christian Haul wrote:
> >
> > > > the defaults module is superceeded by the xmlfile module.
> > >
> > > Is it? Forrest uses this:
> > >
> > > <component-instance name="defaults"
> > > class="org.apache.cocoon.components.modules.input.DefaultsMetaModule">
> > > <values>
> > > <skin>forrest-site</skin>
> > > <base-url>/forrest</base-url>
> > > </values>
> > > </component-instance>
> > >
> > > Can't see how XMLFileModule replaces it.
> >
> > OK, OK, we're not going to remove it ;-) IMO the XMLFile module is
> > much more versatile than the key-value pair model of the defaults
> > module. Both target a very similar task, thus I felt that defaults is
> > not needed anymore.
>
> Yes, but constructing a DOM and doing a JXPath lookup is way more
> expensive than Configuration.getChild().
>
> Hrm.. I think DefaultsMetaModule isn't actually a meta module:
>
> public class DefaultsMetaModule extends AbstractLogEnabled
> implements InputModule, Configurable, ThreadSafe {
>
> Guess it should be renamed. Just as well Cocoon is in perennial
> pre-alpha :)
Yes -- but it is contained in 2.0.4 as well.
> Btw, mind if I move that nifty XSPModuleHelper class into
> o.a.c.c.modules? It's being used in LinkRewriterTransformer now.
No - actually, I think that it might make sense to merge it with the
AbstractMetaModule, they share some code, I believe (XSPModuleHelper
doesn't do alternatives, though). It would allow us to compose the
JXPathModule from it and let it inherit from AbstractJXPathModule
reducing code duplication there as well. I'm currently a little slim
on spare time -- I have been planing to do it for some time now.
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
