cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@infoplanning.com>
Subject Re: Configuration Patterns and Sitemap Generation
Date Wed, 25 Oct 2000 19:07:53 GMT

----- Original Message ----- 
From: "Giacomo Pati" <pati_giacomo@yahoo.com>
To: <cocoon-dev@xml.apache.org>
Sent: Wednesday, October 25, 2000 5:39 AM
Subject: Re: Configuration Patterns and Sitemap Generation


> > > Berin Loritsch wrote:
> > 
> > > > 2) There are many dynamically created method names that
> > > >    aren't needed either.
> > > > 
> > I think we should pre-create all the different ResourcePipeline
> > objects,
> > and the matcher would choose the pipeline.  The tricky part is the
> > Selector
> > pattern.  The selector (based on browser or accepts attribute) should
> > be
> > integrated into the ResourcePipeline.  We can do this by creating
> > inner
> > classes (messy, but it would work) for the Selectors, and add the
> > selector
> > to the rightful part of the pipeline (generator, translator, or
> > serializer).
> > Much like the RuleBasedFactory class in the Avalon proposal tree
> > works.
> 
> I don't think it can work that way. You must know that the
> Matchers/Selectors we have in CVS are only examples. You can write any
> Matcher/Selector based on any dynamics you can think of (and I beleve
> people will do it soon). The thing I've thought of is implementing
> Recyclable in the ResourcePipeline class and build a pool out of'em to
> avoid garbage collection and memory allocation during request time.
> 
> But if you can show me how to do it anyway I'll be happy anyway :)

I think I'll leave this beast alone for a while.  Now that I've caused
all this damage....  Actually the changes I did merely optimized things
a bit, and allowed the pattern to be any arbitrary type.  Enabling them
to be precompiled.


Mime
View raw message