cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Huttar" <lars_hut...@sil.org>
Subject RE: Wildchar URI matchers inclusive or exclusive?
Date Mon, 13 Oct 2003 19:08:13 GMT
Hello,
I'm not highly experienced with Cocoon but I read about sitemap/
matcher semantics recently so here's my 2 cents:

> Is it true that nested wildchar URI matchers are "inclusive" 
> and trigger on
> _all_ matches, while the top level matchers are "exclusive" 
> and trigger on
> _first match_ only?

I don't believe there's any difference between top-level
and nested matchers in this regard. The different behavior
shown by your example can be explained in other ways.
(Geoff's example shows an example of top-level matchers
that should be equivalent to your nested matchers.)

> I noticed that Cocoon 2.1 behaves like that and could not 
> confirm it from
> the documentation.
> 
> For instance, with the following sitemap fragment:
> 
>   <map:pipeline>
>     <!-- Top level matcher -->
>     <map:match pattern="*/events/**.html">
> 
>       <!-- Nested matcher 1 -->
>       <map:match pattern="*/events/index.html">
>         <map:generate src="cocoon:/xpg/{1}/even-home"/>
>       </map:match>
> 
>       <!-- Nested matcher 2 -->
>       <map:match pattern="*/events/*.html">
>         <map:generate src="cocoon:/xpg/{1}/even-{2}"/>
>       </map:match>
> 
>       <!-- Transformation + serialization -->
>       <map:call resource="xpg-xhtml"/>
>     </map:match>
>   </map:pipeline>
> 
> If I request URI fr/events/index.html, both nested matchers 1 + 2 will
> trigger, resulting in a "Generator already set. You can only 
> select one
> Generator" message.

The sitemap processor compares the first match (*/events/**.html)
to the URL, and finds that it matches. It then moves to execute
the contents.
Nested matcher 1 succeeds in matching, so it executes its
"generate" instruction. Then, BECAUSE IT FINDS NO SERIALIZER
(or reader) in matcher 1, it continues on to the next part,
nested matcher 2.
This has nothing to do with the fact that the matchers are nested.
The sitemap evaluator continues execution until the pipeline
is complete (has a serializer).

> 
> Now, if the sitemap is written as:
> 
>   <map:pipeline>
>     <!-- Top level matcher 1 -->
>     <map:match pattern="*/events/index.html">
>         <map:generate src="cocoon:/xpg/{1}/even-home"/>
>         <map:call resource="xpg-xhtml"/>
>     </map:match>
> 
>     <!-- Top level matcher 2 -->
>     <map:match pattern="*/events/*.html">
>       <map:generate src="cocoon:/xpg/{1}/even-{2}"/>
>       <map:call resource="xpg-xhtml"/>
>     </map:match>
>   </map:pipeline>
> 
> and if I request the URI fr/events/index.html, then only the 
> first matcher
> will trigger.

I expect this is because <map:call resource="xpg-xhtml"/>
involves a serializer; but I'm not sure what that instruction
does.

> I believe this is the intended behavior, but could someone confirm it?

As Geoff Howard said, try his example and see if the behavior
is different. My understanding is that his example should
behave the same as your nested-matcher example.

Lars


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message