cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
Subject Re: Input module chaining (Re: XML input module)
Date Sat, 05 Oct 2002 07:07:53 GMT
On Fri, Oct 04, 2002 at 06:07:14PM +0200, Christian Haul wrote:
> On 03.Oct.2002 -- 07:42 PM, Piroumian Konstantin wrote:
...
> > > In this model, every module is potentially a 'meta' module, 
> > > as it can take as input any other module. Think of 
> > > 'input-module' as 'stdin'.
> > 
> > This is exactly what I would like to have. 
> > But I think that we should have simple modules declared in Cocoon
> > distribution by default and users should be able to combine them as they
> > like.
> 
> I'm referring _only_ to the "if (!present) then use otherModule"
> case. This should IMO be done by a separate module.

Do you mean when, say {moduleA:foo} is requested, but moduleA doesn't
have an attribute called 'foo'?

I can see why you wouldn't _always_ want values to be defaulted to
moduleB, but that does seem very useful behaviour to support.

So how would it be done with a separate module?

...
> > > As for inheritance, that's just a handy technique for 
> > > implementing chaining. We'd have:
> > > 
> > >     AbstractInputModule
> > >             |
> > >  AbstractChainedInputModule   (handles 'input-module' and 
> > > name mapping)
> > >             /\
> > >           /    \
> > >         /        \
> > > DateFormatter  AbstractJXPathModule
> > >                       |
> > >                       \_ RequestModule
> > >                       \_ SessionModule
> > >                       \_ XMLModule
> > 
> > +1
> > And even date formatter can be JXPath aware, e.g. you can use substring()
> > function to extract parts of the date string.
> 
> This looks better than it is, since the composition part (and keeping
> references if threadsafe) can not be separated that easily IMO because
> of the try-catch-finally split.

Looking at all the *MetaModule.java files, there is a huge amount of
duplicated, non-trivial code. I don't fully understand it, and so cannot
easily turn XMLModule into XMLMetaModule. Wouldn't it be possible to
separate the common code out into an AbstractMetaModule class, which the
*MetaModules could inherit from?


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

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


Mime
View raw message