cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: The Problems with Sitemap Factories
Date Fri, 12 Oct 2001 09:59:05 GMT
Hi Sylvain,

> Sylvain Wallez wrote:
>
> +1. I find these too much complicated and like the idea of an
> interpreded sitemap, and even more flowmaps !
>
> But in order to still have a good performance we need a way for some
> matchers to prepare patterns (e.g. precompile regexps) during sitemap
> initialization. So what about a "PreparedMatcher" ?
>
> interface Matcher {
>   Map match (Object pattern, Map objectModel, Parameters parameters);
> }
>
> interface PreparedMatcher {
>   Object prepare(String pattern);
>   Map match (Object pattern, Map objectModel, Parameters parameters);
> }
>
> As you see, this requires a little modification of the Matcher interface
> since the "pattern" parameter will be an Object :
> - it's the pattern String (as now) for non-prepared matchers,
> - it's the object returned by prepare() for prepared matchers
>
> Or we can also simply add prepare() to Matcher and have AbstractMatcher
> return the pattern as is.
>
Could you give an example of a real matcher and how that would implement
the interface?

> I don't know if Selectors could also benefit from a "PreparedSelector".
>
> And since we're talking about matchers and selectors, a few thoughts
> (for 2.1 ?) :
> - What about giving matchers and selectors access to the source resolver
> ?
I can remember that we had a discussion on this, but I can't remember
the agreement we made. Do you recall it?
If anything is against it, we should add the source resolver to the
interfaces *if* we change the interfaces anyway.

> - I've always been confused that selectors don't have a method called on
> "map:select" to set up a context that could be reused between the
> different "map:when" alternatives. In many cases this would allow to
> reduce select() to a simple equality test and thus speed up processing.
>
Could you please give an example here, too?

Carsten

> Sylvain.
>
> Carsten Ziegeler a écrit :
> >
> > Hi Team,
> >
> > I would like to propose that we get rid of the sitemap factories,
> > the selector and matcher factory.
> >
> > I see at least three reasons for this:
> > - If you want to use a matcher factory inside a subsitemap,
> >   you currently MUST redefine it in the subsitemap as it is
> >   not "inherited" from the parent sitemap. This is true
> >   of course also true for selectors (I entered this already
> >   in bugzilla).
> >   Using matchers and selectors in subsitemaps becomes very
> >   error prone as you always as a sitemap editor have to be
> >   aware if it is *implemented* as a factory or not. I think
> >   the sitemap editor does not have to know about such technical
> >   details.
> > - The factories are hard to code. Java code generated from strings
> >   is not so easy to write.
> > - This is needed for the new RT, like the recent Tree traversal approach
> >
> > So I'm +3 on removing the factories and this even for the final release!
> >
> > Carsten
> >
> > Open Source Group                        sunShine - b:Integrated
> > ================================================================
> > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > www.sundn.de                          mailto: cziegeler@sundn.de
> > ================================================================
>
> --
> 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


Mime
View raw message