Hi all,
I have a recurring theme in a few of my sitemaps and, although I
have solved the problem, I'm not particularly happy with the solution.
Here's the problem in pseudo-sitemapese:
<map:match pattern="*.html">
<map:act desc="an action to be applied to all xhtml">
<map:match pattern="a*.html" desc="source A-prefixed xhtml">
<map:generate/>
<map:transform/>
</map:match>
<map:match pattern="b*.html" desc="source B-prefixed xhtml">
<map:generate/>
<map:transform/>
</map:match>
<map:match pattern="*.html" desc="source of all other xhtml">
<map:generate/>
<map:transform/>
</map:match>
<map:transform desc="a common template to apply regardless of source"/>
<map:serialize/>
</map:act>
</map:match>
The above doesn't work when coded with matchers. C2 falls through
the nested matches, hits the generic case and obviously throws
an exception because it tries to call a second generator.
There are some obvious solutions to this problem. One is to copy
the common transform and serialize stages into each of the
nested matches, forcing C2 to stop processing in the individual
nested matches. Slightly cleaner is to put the final transform/
serialize step in a resource and have each of the nested matches
call the resource. I really don't like the finality of resources,
however - they feel too much like goto statements.
What I think I want to do here is use the "if-then-else" processing
model of selectors. Choose only one of the a*, b* or * patterns,
generate the xhtml, and finish by applying the final transform/
serialization regardless of source.
However, the documentation states that selectors were designed with
the intent of choosing between well-defined values. Indeed, none
of the shipped selectors use patterns or regexps. I'm crafty enough
at writing my own components that I can easily write a selector that
takes a regular expression as a test argument instead of a constant.
I would rather not go against design philosophy, however, if there
is a better way to solve this class of problem.
Does anyone have thoughts on refactoring this class of problem?
Thanks, Jonathan
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
