cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <>
Subject RE: Allowed Sitemap Constructs
Date Mon, 07 Jan 2002 13:52:15 GMT
> From: Stefano Mazzocchi []
> 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
> > executed right before <map:handle-errors/>.
> Gosh, if this is your vision, we have a problem.

No, that's not my vision: that's the reality we live in.

1. Quoting Carsten:
 - the sitemap is processed top-down, the processing stops:
   * when a serialize is reached
   * when a reader is reached
   * when the end is reached

It exactly means that this last <act> will be executed when mentioned
conditions are met.

2. Quoting current sitemap.xsl:

  try {
    <xsl:for-each select="map:match"> //This is to be changed on:
    <xsl:if test="position() = last()">
      throw new ResourceNotFoundException("No pipeline matched request:
" + environment.getURIPrefix()+'/'+environment.getURI());
  } catch (...Exception e) {
    // Error handling goes here...

> 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.

That's how it is done currently. Feel free to put it on top of the
Our opinions do not differ here.

> 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.

My vision was that map:pipeline *must* have at least one generator and
serializer (or reader, or mount), and any number of transformers. And
map:match is one of the tools allowing to choose them depending on the

Here is an example to clarify this...


This *is* legal. Now, is this leagal or not:


It is semantically identical, but broken on two physical pieces. If you
merge these two physical pieces into one entity, it would not differ
previous example. Tell me why this second example is wrong and not

> 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.
> So, yeah, I was wrong, there is a possibility when these post-actions
> are reachable, but only when no matchers are found, the other example
> you provide should not be possible.

Ok. Now let's hear your opinion why other example is not possible ;)


To unsubscribe, e-mail:
For additional commands, email:

View raw message