Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3BD3F54F.87906F25@anyware-tech.com>
Date: Mon, 22 Oct 2001 12:30:39 +0200
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: New PreparedMatcher, deprecation of CodeFactory
References: <GMEBIBHGAOFGJCDPJANDAEIPCPAA.cziegeler@sundn.de>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit


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