On Mon, 7 Jan 2002, Stefano Mazzocchi wrote:
> Vadim Gritsenko wrote:
>
> > Not exactly correct... they are reachable...
> >
> > >
> > > <pipeline>
> > > <act>
> > > <match>
> > > <act>
> > > <match>
> > > <act>
> > > </pipeline>
> > >
> > > the third one is never reached.
> >
> > It *is* reached if none of the matchers are matched *or* if matched
> > matchers had no <map:serialize|mount>. In these cases, last actions is
> > executed right before <map:handle-errors/>.
>
> Gosh, if this is your vision, we have a problem.
>
> The original design was that 'handle-errors' should be sort of a
> try/catch statement, not a procedural call that you can assume to be
> called at the end. It's not *at the end* of the pipeline. It could be
> explicitly written on top or in between, things shouldn't change.
Sefano is right! The <handle-error> *is* implemented as a try/catch
statement.
> Also, and more important, if a matcher doesn't have a
> mount|serializer|reader, it's an error. The sitemap shouldn't even be
> loaded.
But this isn't the case today. You can code
<match pattern="a*">
<generate type="a" .../>
</match>
<match pattern="b*">
<generate type="b" .../>
</match>
<match pattern="*foo">
<transform .../>
<serialize .../>
</match>
which results in a pipeline of
url="afoo": G(a)->T->S
url="bfoo": G(b)->T->S
> At the same time, I see your point: the post-action can be executed if
> no matcher is entered... and we can't forbid this to happen unless we
> force the creation of a new semantic like 'default-match', which I
> think, sucks.
Big time. Today it will result a ResourceNotFound
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
