cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <pati_giac...@yahoo.com>
Subject Re: Configuration Patterns and Sitemap Generation
Date Wed, 25 Oct 2000 09:39:38 GMT

--- Berin Loritsch <bloritsch@infoplanning.com> wrote:
> ----- Original Message ----- 
> From: "Stefano Mazzocchi" <stefano@apache.org>
> To: <cocoon-dev@xml.apache.org>
> Sent: Tuesday, October 24, 2000 5:38 AM
> Subject: Re: Configuration Patterns and Sitemap Generation
> 
> 
> > Berin Loritsch wrote:
> > > 
> > > I noticed that the compiled sitemap idea can be improved
> > > now that the new Avalon is integrated.  I will enumerate
> > > the methods, and it might be that the Sitemap no longer
> > > needs compilation.
> > > 
> > > 1) configure() passes the configuration object to the
> > >    parent, and then proceeded to create a bunch of
> > >    SAX events to feed the SAXConfigurationBuilder and
> > >    build a new Configuration object.
> > > 
> > > This is no longer necessary.  The purpose of the
> > > Configure method is to configure *this* object.
> > > Avalon includes a DefaultConfiguration object where
> > > you can directly build Configuration trees.  This results
> > > in much cleaner code already.
> > > 
> > > However, a Sitemap object only needs to read the
> > > Configuration tree and create the matchers, transformers,
> > > serializers, readers, and other components.
> 
> This part is accomplished.  It is lighter weight in that it
> doesn't use a heavy DOM, or hundreds of method calls (SAX)
> to accomplish the same results.  This makes both compilation
> and initialization quicker.  The SitemapComponentManager
> does not yet conform to the Avalon principles of Roles
> being the work interface.
> 
> > > 2) There are many dynamically created method names that
> > >    aren't needed either.
> > > 
> > > Avalon includes a ComponentSelector that can take any
> > > object as a hint.  That means that you can feed the
> > > URL or string directly to the ComponentSelector, and the
> > > correct matcher/pipeline would be returned based on the
> > > logic surrounding the Selector.
> > > 
> > > Ex.  I have 3 matchers: "html/*", "", and "**.pdf".
> > > 
> > > My SitemapMatcherSelector will take any uri and return
> > > the appropriate value:
> > > 
> > > matcher = (Matcher) selector.select("html/foo");
> > > 
> > > returns the first matcher,
> > > 
> > > matcher = (Matcher) selector.select("foo/bar/baz.pdf");
> > > 
> > > returns the last matcher,
> > > 
> > > matcher = (Matcher) selector.select("");
> > > 
> > > returns the second matcher.
> > > 
> > > I think this beats generating a bunch of if statements
> > > and creating method names and such.
> > 
> > Beats in terms of simplicity or performance?
> 
> Simplicity definitely.  Performance?  well that remains to be seen.
> 
> > I don't think you can be faster than a compiled sitemap.... and we
> don't
> > compile because it's easier (it's not!) but because it's faster....
> 
> I was looking at the compiled class.  I think there are ways that it
> can
> be optimized for both speed and simplicity/clarity.  I have to think
> about
> the exact "how", but I believe it is possible.
> 
> > Anyway, I agree that having an "interpreted" sitemap would be
> totally
> > cool for development stages compared to having to recompile the
> whole
> > thing over and over again.... but when going in production,
> compiling to
> > bytecode would still make perfect sense to me, even if the
> generated
> > code is a mess.
> 
> I don't mind the generated code being a mess.  I think we can make it
> a
> bit more optimized than general if/then statements.
> 
> Where can I read up on the ideas behind the sitemap?  There is a
> potential
> disconnect between what we are specifying and what we are
> implementing.  What
> we have is a new ResourcePipeline object for _every_ request--mainly
> because
> based on the matchers the different destinations are different.
> 
> 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 :)

Giacomo


=====
--
PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7                     Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen                    Web:   http://www.pwr.ch

__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/

Mime
View raw message