You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@anyware-tech.com> on 2001/10/19 17:57:09 UTC
New PreparedMatcher, deprecation of CodeFactory
Hi team,
You'll find in the HEAD the new PreparedMatcher interface we talked
about and a new implementation of all factory-based matchers with this
interface (way simpler).
CodeFactory is now deprecated and shouldn't be used for new matchers and
selectors. I will also port Selector so that we can totally stop using
it. This is the key for the tree-traversal implementation of the
sitemap.
CodeFactory matchers and selectors needed to be redeclared in
subsitemaps, and unfortunately this is still the case with
PreparedMatchers : it isn't possible to know when generating code for a
subsitemap the actual class for an inherited matcher, and thus we cannot
know if it's a simple Matcher or a PreparedMatcher. This won't be the
case with the interpreted sitemap.
Another behavior which also existed with code factories : since patterns
are prepared once at sitemap startup, patterns for PreparedMatchers
cannot use "{...}" substitution while simple Matchers can. This will
still be the case with an interpreted implementation.
Samples seem to behave correctly with these changes.
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
Re: New PreparedMatcher, deprecation of CodeFactory
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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
RE: New PreparedMatcher, deprecation of CodeFactory
Posted by Carsten Ziegeler <cz...@sundn.de>.
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!!
> 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.
>
> 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.
The performance loss at request time seems unavoidable.
>
> <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!
Carsten
> Sylvain.
>
> > Carsten
> >
> > > -----Original Message-----
> > > From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> > > Sent: Friday, October 19, 2001 5:57 PM
> > > To: cocoon-dev
> > > Subject: New PreparedMatcher, deprecation of CodeFactory
> > >
> > >
> > > Hi team,
> > >
> > > You'll find in the HEAD the new PreparedMatcher interface we talked
> > > about and a new implementation of all factory-based matchers with this
> > > interface (way simpler).
> > >
> > > CodeFactory is now deprecated and shouldn't be used for new
> matchers and
> > > selectors. I will also port Selector so that we can totally stop using
> > > it. This is the key for the tree-traversal implementation of the
> > > sitemap.
> > >
> > > CodeFactory matchers and selectors needed to be redeclared in
> > > subsitemaps, and unfortunately this is still the case with
> > > PreparedMatchers : it isn't possible to know when generating
> code for a
> > > subsitemap the actual class for an inherited matcher, and
> thus we cannot
> > > know if it's a simple Matcher or a PreparedMatcher. This won't be the
> > > case with the interpreted sitemap.
> > >
> > > Another behavior which also existed with code factories :
> since patterns
> > > are prepared once at sitemap startup, patterns for PreparedMatchers
> > > cannot use "{...}" substitution while simple Matchers can. This will
> > > still be the case with an interpreted implementation.
> > >
> > > Samples seem to behave correctly with these changes.
> > >
> > > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: New PreparedMatcher, deprecation of CodeFactory
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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.
Other changes :
- renamed PreparedMatcher to PreparableMatcher which now extends
Matcher. The "-able" suffix denotes an optional feature :
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.
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.
<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...
Sylvain.
> Carsten
>
> > -----Original Message-----
> > From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> > Sent: Friday, October 19, 2001 5:57 PM
> > To: cocoon-dev
> > Subject: New PreparedMatcher, deprecation of CodeFactory
> >
> >
> > Hi team,
> >
> > You'll find in the HEAD the new PreparedMatcher interface we talked
> > about and a new implementation of all factory-based matchers with this
> > interface (way simpler).
> >
> > CodeFactory is now deprecated and shouldn't be used for new matchers and
> > selectors. I will also port Selector so that we can totally stop using
> > it. This is the key for the tree-traversal implementation of the
> > sitemap.
> >
> > CodeFactory matchers and selectors needed to be redeclared in
> > subsitemaps, and unfortunately this is still the case with
> > PreparedMatchers : it isn't possible to know when generating code for a
> > subsitemap the actual class for an inherited matcher, and thus we cannot
> > know if it's a simple Matcher or a PreparedMatcher. This won't be the
> > case with the interpreted sitemap.
> >
> > Another behavior which also existed with code factories : since patterns
> > are prepared once at sitemap startup, patterns for PreparedMatchers
> > cannot use "{...}" substitution while simple Matchers can. This will
> > still be the case with an interpreted implementation.
> >
> > Samples seem to behave correctly with these changes.
> >
> > 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
RE: New PreparedMatcher, deprecation of CodeFactory
Posted by Carsten Ziegeler <cz...@sundn.de>.
Hi Sylvain,
thanks for this work, but we should make the PreparedMatcher work
in subsitemaps.
I didn't had time to look into the generated code for very long,
but I think the problem lies in the test, if the matcher is
a PreparedMatcher. This is currently done in the stylesheet.
If we move this into the generated code it should work. So the
generated code could look like this:
- lookup matcher
- if (matcher instanceof PreparedMatcher)
- prepare patterns
- release matcher
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?
Carsten
> -----Original Message-----
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> Sent: Friday, October 19, 2001 5:57 PM
> To: cocoon-dev
> Subject: New PreparedMatcher, deprecation of CodeFactory
>
>
> Hi team,
>
> You'll find in the HEAD the new PreparedMatcher interface we talked
> about and a new implementation of all factory-based matchers with this
> interface (way simpler).
>
> CodeFactory is now deprecated and shouldn't be used for new matchers and
> selectors. I will also port Selector so that we can totally stop using
> it. This is the key for the tree-traversal implementation of the
> sitemap.
>
> CodeFactory matchers and selectors needed to be redeclared in
> subsitemaps, and unfortunately this is still the case with
> PreparedMatchers : it isn't possible to know when generating code for a
> subsitemap the actual class for an inherited matcher, and thus we cannot
> know if it's a simple Matcher or a PreparedMatcher. This won't be the
> case with the interpreted sitemap.
>
> Another behavior which also existed with code factories : since patterns
> are prepared once at sitemap startup, patterns for PreparedMatchers
> cannot use "{...}" substitution while simple Matchers can. This will
> still be the case with an interpreted implementation.
>
> Samples seem to behave correctly with these changes.
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org