I hadn't realized that it was possible to include template parameters as part
of the template match rule.
It isn't! It's a feature that I would sometimes like to have, and that other
people also seem in favour of. But at the moment, local parameters are not in
scope for the match pattern.
Michael Kay
Saxonica
That would definitely simplify some things that I was doing recently where I
was matching more general cases and then, upon checking against the template
parameter, I would call "xsl:next-match" to choose the next-in-line template.
Excellent, I'll go back and give that a shot.
Thanks for the excellent tip.
On Tue, May 19, 2020 at 3:21 AM BR Chrisman brchrisman(_at_)gmail(_dot_)com
<mailto:brchrisman(_at_)gmail(_dot_)com>
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com
<mailto:xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com>> wrote:
ohhh xsl:mode enclosing templates.. I use that a lot in generated
stylesheets... it just makes so much sense.... looking forward to
that!
On Mon, May 18, 2020 at 11:52 AM Graydon graydon(_at_)marost(_dot_)ca
<mailto:graydon(_at_)marost(_dot_)ca>
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com
<mailto:xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com>> wrote:
On Mon, May 18, 2020 at 05:04:12PM -0000, Michael Kay
mike(_at_)saxonica(_dot_)com <mailto:mike(_at_)saxonica(_dot_)com> scripsit:
I didn't want to create messy scoping rules for variables, e.g.
<xsl:template match="type(xs:integer)" mode="increment" select=".+1"/>
is fine, but
<xsl:template match="type(xs:integer)" mode="increment" select=".+$delta">
<xsl:param name="delta" as="xs:integer"/>
</xsl:template>
feels a bit weird.
I can't speak to feel at all, and I have no knowledge of how difficult
it makes the scoping rules to implement, but that second example is to
me obviously ever so much more useful. It implies one could do things
like perform a simple numbering pass and then have one template that
went through and attached all the appropriate names -- part, chapter,
section, etc. -- on a second pass by matching the numbers, with the text
provided by parameter.
We had similar issues with xsl:iterate - the reason xsl:on-completion
comes first is to avoid creating custom rules for variable scoping.
Using params in match patterns gets even more interesting - useful, but
hairy:
<xsl:template match="para[@class=$class]">
<xsl:param name="class"/>
...
</xsl:template>
I cannot tell you how many times I have wanted to be able to do that.
There's -- I think there is -- an appropriate caution with template
predicates so that you have templates to match every possible, rather
than every expected, case. Being able to stuff all of that logic into
whatever singular thing assigns the value to $class, rather than
distributing it over a bunch of templates' individual predicates, would
be extremely helpful.
(And yes it starts to be a special case of XPath macros, but I would
like those, too.)
--
Graydon Saunders | graydonish(_at_)gmail(_dot_)com
<mailto:graydonish(_at_)gmail(_dot_)com>
Þæs oferéode, ðisses swá mæg.
-- Deor ("That passed, so may this.")
XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/293509> (by
email <>)
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--