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 Tue, 24 Oct 2000 19:30:34 GMT
----- 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.


Mime
View raw message