On Dec 3, 2006, at 1:27 PM, Mark Lundquist wrote:
7) There would be a globally configurable property to take the place
of the local @value attribute. To invoke a (non-default) configured
instance, you use <match type="..."> just like today, but that is not
any lighter syntactically than just using @value. The real reason for
this is to be able to configure a more specific default, e.g.
<matchers default="uri">
<matcher name="general" class="..."> <!-- Note: the concrete class
is always the same! -->
</matcher>
<matcher name="uri" class="...">
<value>{request:URI}</value>
</matcher>
<matcher class="...">
</matchers>
This allows you to just write
<match path="foobar/**/*">
which is nearly identical to today's <match pattern="foobar/**/*">
where <matchers default="wildcard">. The tradeoff is that you then
have to use <match type="general"> for anything else... but you have
the choice if you want to do it that way.
Bah, I still had some "old skool" thinking goin' on there myself...
Instead of a <value> configuration element that precludes a local
@value attribute, the element should be called <default-value> and it
should just configure a default if @value is omitted. You can still
override the default with @value. So:
<match path="**" /> <!-- perfectly good... -->
<match value="{request-param:foo}" equals="true" /> <!-- also
perfectly good, no need for @type or a different matcher instance -->
—ml—
