Stefano wrote:
> <matcher type="M1">
> <matcher type="M2">
> <act type="A1">
> <act type="A2">
> <read src="{A2.a}/{A1.b}/{M1.c}/{M2.d}/{request:param}"/>
> </act>
> </act>
> </matcher>
> </matcher>
>
> where the only problem is the nesting of two components of
> the same type
> (but I don't really see a need for this and I would think
> it's a design
> mistake of the component if you need to do it!)
Yes it probably is a design mistake ... but what about referring to the
component by name, rather than type?
Someone else suggested xpath, and there was some discussion that some xpath
expressions would cause problems with nested sitemaps, but an xpath like
"id('foo')" would not have this problem. Or, if not xpath, a simpler naming
scheme could be used like:
<matcher type="M1" id="some-meaningful-label">
<matcher type="M2" id="another-meaningful-label">
<act type="A1" id="another-label">
<act type="A2" id="whatever">
<read
src="{#some-meaningful-label/a}/{#another-meaningful-label/b}/{#another-labe
l/c}/{#whatever.d}/{request:param}"/>
</act>
</act>
</matcher>
</matcher>
OK maybe my labels are too long ;-) but it is at least an absolutely clear
way to refer to the variable, which doesn't involve counting the number of /
characters. Plus it has the advantage of helping to document the use of each
component in the pipeline.
Just my 2c (and that's 2 NZ cents BTW - just a bit less than 1 US cent)
Con
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
