cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Lundquist ...@wrinkledog.com>
Subject Re: [RT] Improved matching & selecting
Date Mon, 04 Dec 2006 15:41:12 GMT

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—


Mime
View raw message