> From: Jonathan Layes [mailto:[EMAIL PROTECTED]]
> 
> On Mon, Jun 10, 2002 at 11:35:58AM -0400, Vadim Gritsenko wrote:
> > > From: Christian Haul [mailto:[EMAIL PROTECTED]]
> > > > > From: Christian Haul
[mailto:[EMAIL PROTECTED]]
> > > > > > Nope, this is not a bug. Sitemap works this way, breaking
> > > > > > execution
> > > > > > on
> > > > > > first serialize.
> > > > >
> > > > > Sure, but have a second look at the code: There's only one
> > > > > serialize.
> > > >
> > > > Yup, one serialize. It means every request will get through:
match,
> > > > generator, transformer, match, generator... Oops! Exception:
can't
> > > > have two generators.
> > >
> > > Oh, haven't realized that the last match matches everything and
then
> > > two generators are used. But apart from using two generators, the
> > > snippet should work, right? Like using a regex-matcher and
matching
> > > "[^ab]*.html"
> >
> > Yes, if you make matcher patterns so they do not intersect,
everything
> > will be OK.
> 
> My first interpretation of the docs was much like Christian's - only
> the first successful matcher at a given nest level will run.  But
> further investigation and experimentation led me to conclude what
> Vadim pointed out:  the subpipeline will keep executing matchers
> until a serializer is reached.

You might have many levels of nesting with actions/matchers/selectors in
any combinations. They do not indicate that pipeline has been assembled,
but just route sitemap engine through sitemap, allowing to choose
desired branch(es) according to the state of the system (URL / headers /
request attributes / session attributes / etc).


> Sometimes this behaviour is convenient and sometimes it isn't.
> In the example I provided where I want a default, catch-all case
> to apply to everything that hasn't matched earlier in the subpipeline,
> it isn't convenient.  However, I don't think changing the behaviour
> of matchers is a good idea as it would seriously break existing
> sitemaps.
> 
> The default, catch-all case is where the selector model seems a
> better fit.  However, selectors really weren't designed for
> pattern matching.  For starters, a new map isn't created with
> selectors so extracting parts of the matched pattern doesn't
> really work.  Christian, thanks for pointing out SwitchSelector
> in CVS, though.  That is the class from which I'd derive such a
> pattern-matching selector if I decide it's a good idea.
> 
> Vadim, what is your opinion on dealing with this type of situation?

Yes, selectors are somewhat limited comparing to matchers. And yes, in
choose-only-one-from-many-options situation selector should be used.

Vadim



---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Reply via email to