cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: New PreparedMatcher, deprecation of CodeFactory
Date Mon, 22 Oct 2001 13:38:22 GMT


Carsten Ziegeler a écrit :
> 
> Sylvain Wallez wrote:
> >
> > Carsten Ziegeler a écrit :
> > >
> > > Hi Sylvain,
> > >
> > Hi Carsten,
> >
> > > thanks for this work, but we should make the PreparedMatcher work
> > > in subsitemaps.
> >
> > I just commited some additional work : subsitemaps work ! No need to
> > redeclare inherited selectors and matchers.
> >
> Absolutely great work, Sylvain!!

Thanks :)

> > Other changes :
> > - renamed PreparedMatcher to PreparableMatcher which now extends
> > Matcher. The "-able" suffix denotes an optional feature :
> +1
> 
> > PreparableMatchers can be used also as regular matchers.
> > - rewrote all factory-based selectors as regular selectors.
> >
> > I think we can now abandon the use of CodeFactory.
> Yes, great! I'm +1 on removing all this CodeFactory stuff completly.

+10 !

> >
> > The performance cost of these changes is mainly at sitemap
> > initialization time, where all patterns must be prepared, causing a
> > select/release for each pattern. At request time, which is the most
> > important, the cost is low : a select/release, a test and a cast.
> The performance lost at initialization time is no real problem,
> we could later on improve performance by either sorting the patterns
> by used matcher to lookup/release each matcher only once, or
> we could lookup all matchers beforehand, create the patterns
> and release them afterwards.

Right. I'd like to concentrate now on the tree-traversal sitemap. So, if
someone else wants to do this optimisation, welcome !

> The performance loss at request time seems unavoidable.

A possible optimisation is to select once ThreadSafe implementations at
setup time. Since most of matchers/selectors are ThreadSafe, this would
greatly reduce the number of select/release. But this isn't possible
with the compiled sitemap, since we cannot test the class at code
generation-time (otherwise inheritance in subsitemaps doesn't work). So
I keep this idea for the tree-traversal.

> >
> > <snip/>
> >
> > > The second problem, when the pattern contains {...}, is it possible
> > > to test the pattern when the sitemap is generated and then only
> > > use the PreparedMatcher interface, if no {...} is found?
> >
> > Yes, it can be done. However, since the '{' and '}' are also part of the
> > Regexp syntax, we'll have to add an escaping syntax for these
> > characters, such as '\{' when sitemap substitution isn't wanted.
> >
> > I'm now working on this...
> >
> Hey, unbelievable! Keep on!

Done ! We can now use {..} substitution in patterns, and if the braces
are part of the pattern and shouldn't go through sitemap substitution,
they can be escaped with '\{'. Of course, if there's substitution in a
pattern, PreparableMatchers are used like regular Matchers (no pattern
preparation).

Sylvain.
-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

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


Mime
View raw message