You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jeremy Quinn <je...@media.demon.co.uk> on 2003/03/13 12:45:37 UTC
Module Sample
Hi All
The Modules sample is broken.
It relies on two (missing) input-modules in cocoon.xconf (I believe).
One named 'defaults' the other named 'myxml'.
These appear to have been removed from cocoon.xconf a while ago, before
CVS re-factoring (?).
Are these supposed to be set up in a different way now, or shall I put
them back into cocoon.xconf?
thanks
regards Jeremy
Re: Module Sample
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
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
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: Module Sample
Posted by Jeff Turner <je...@apache.org>.
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 :)
Btw, mind if I move that nifty XSPModuleHelper class into
o.a.c.c.modules? It's being used in LinkRewriterTransformer now.
--Jeff
> 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
Re: Module Sample
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
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.
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
Re: Module Sample
Posted by Jeff Turner <je...@apache.org>.
On Thu, Mar 13, 2003 at 01:44:37PM +0100, Christian Haul wrote:
> On 13.Mar.2003 -- 11:45 AM, Jeremy Quinn wrote:
> > Hi All
> >
> > The Modules sample is broken.
> >
> > It relies on two (missing) input-modules in cocoon.xconf (I believe).
> >
> > One named 'defaults' the other named 'myxml'.
>
> 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.
> hence i wouldn't add it back. myxml -- don't know.
'myxml' was defined purely for the samples. It was an XMLFileModule instance,
using some dreamed-up XML:
<forrestconf version="1.0">
<skin>avalon-tigris</skin>
<base-url>/mysite</base-url>
</forrestconf>
> > These appear to have been removed from cocoon.xconf a while ago, before
> > CVS re-factoring (?).
> >
> > Are these supposed to be set up in a different way now, or shall I put
> > them back into cocoon.xconf?
I don't know of any other mechanism, so I'd guess their removal was a mistake.
--Jeff
>
> 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
Re: Module Sample
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Thursday, March 13, 2003, at 12:44 PM, Christian Haul wrote:
> On 13.Mar.2003 -- 11:45 AM, Jeremy Quinn wrote:
>> Hi All
>>
>> The Modules sample is broken.
>>
>> It relies on two (missing) input-modules in cocoon.xconf (I believe).
>>
>> One named 'defaults' the other named 'myxml'.
>
> the defaults module is superceeded by the xmlfile module.
The 'defaults' module is still referenced by the 'chain' module.
> hence i
> wouldn't add it back. myxml -- don't know.
Well, the sample is using it ....
>
>> These appear to have been removed from cocoon.xconf a while ago,
>> before
>> CVS re-factoring (?).
>>
>> Are these supposed to be set up in a different way now, or shall I put
>> them back into cocoon.xconf?
regards Jeremy
Re: Module Sample
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 13.Mar.2003 -- 11:45 AM, Jeremy Quinn wrote:
> Hi All
>
> The Modules sample is broken.
>
> It relies on two (missing) input-modules in cocoon.xconf (I believe).
>
> One named 'defaults' the other named 'myxml'.
the defaults module is superceeded by the xmlfile module. hence i
wouldn't add it back. myxml -- don't know.
> These appear to have been removed from cocoon.xconf a while ago, before
> CVS re-factoring (?).
>
> Are these supposed to be set up in a different way now, or shall I put
> them back into cocoon.xconf?
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