You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Olivier Lange <ol...@petit-atelier.ch> on 2003/10/13 19:17:25 UTC
Wildchar URI matchers inclusive or exclusive?
Hello all,
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 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.
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 believe this is the intended behavior, but could someone confirm it?
In case it is, I suggest adding a note at least here for this subtle
behaviorial change (I would submit a patch):
http://cocoon.apache.org/2.1/userdocs/matchers/matchers.html#Order
Olivier
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Wildchar URI matchers inclusive or exclusive?
Posted by Geoff Howard <co...@leverageweb.com>.
Olivier Lange wrote:
> Hello all,
>
> 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 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.
Hmm. I think this is a matter of complete vs. incomplete pipelines not
different behavior between top-level and nested matchers. Try the
following:
<map:pipeline>
<!-- Toplevel matcher 1 -->
<map:match pattern="*/events/index.html">
<map:generate src="cocoon:/xpg/{1}/even-home"/>
</map:match>
<!-- Toplevel 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:pipeline>
If that does any differently then we'll need to take a closer look.
> 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 believe this is the intended behavior, but could someone confirm it?
This is what I would expect too. Someone with more history on the
design of the sitemap semantics will need to confirm though. I think
that by design the sitemap keeps examining matchers, selectors, and
actions until it finds a complete pipeline or an error caused by too
many or too few components with no other paths to follow.
> In case it is, I suggest adding a note at least here for this subtle
> behaviorial change (I would submit a patch):
> http://cocoon.apache.org/2.1/userdocs/matchers/matchers.html#Order
Patch welcome - submit it to Bugzilla with [PATCH] as the beginning of
the summary. If the patch is simple, just do one and we can confirm
accuracy on the dev list when the automatic notice arrives. If it's
longer and you'd rather get a definitive answer first, forward this to
the dev list with perhaps a modified subject.
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Wildchar URI matchers inclusive or exclusive?
Posted by Lars Huttar <la...@sil.org>.
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