fpr what my opinion is worth, I generally do a few things:
- have debugging everywhere and strip debug elements/attributes after
output with a separate transform
- preprocess the stylesheet, inserting debug logging (I think one
example was when there was an apply-templates, for-each, or something
similar with parent::xsl:copy, then preprocessor would add an
xsl:attribute with the attribute in a debug namespace ahead of the
instruction with the value count(@select)... or I might've just
polluted the attribute axis, I can't remember this one...)
- I try to split my transforms into smaller pipelined units, so I can
view intermediate result documents (for me, everything except code
generators starts with an identity template, and I split the
commuting/commutative transform elements as much as possible)
(caveat: mostly for data sizes much smaller than available memory)
(caveat: all my work has been in 1.0 though I'm picking up 2.0 stuff,
going through novachev's pluralsight course right now and have found
it to be an excellent resource)
- Brian
I like to keep debug outside of my code as much as possible...
On Mon, Mar 24, 2014 at 10:31 AM, Eliot Kimber
<ekimber(_at_)contrext(_dot_)com> wrote:
For whatever reason I find using interactive debugging unhelpful for
debugging XSLT processing (but I couldn't code a line of Java without it).
Thus I depend very heavily on debug messages in my XSLTs. I used to just
emit messages and then comment them out or delete them when I was done,
but then I found myself recreating those messages when I had to return to
that bit of code.
Then I started using a runtime parameter to turn debugging on or off
globally and using IF checks to output my messages. But that results in a
lot of messages when you've got a lot of debug messages, most of which are
not relevant to your current problem, so back to commenting things out or
disabling the IF check (e.g., test="false() and $doDebug").
Lately I've been trying the technique of using a tunnel parameter to
communicate the debug state to each template or function, which lets me
selectively turn on debugging within a given code path, e.g.:
<!-- Global variable set from runtime parameter -->
<xsl:variable name="doDebug" as="xs:boolean"
select="matches($debug, '(true|yes|1|on)', 'i')"
/>
<xsl:template match="/">
<xsl:param name="doDebug" as="xs:boolean"
tunnel="yes"
select="$doDebug"
/>
<xsl:apply-templates>
<xsl:param name="doDebug" as="xs:boolean"
tunnel="yes"
select="$doDebug"/>
</xsl:apply-templates>
</xsl:template>
<xsl:template match="foo">
<xsl:param name="doDebug" as="xs:boolean"
tunnel="yes"
select="false()"
/>
</xsl:template>
Because you can shadow a parameter within a template, you can create a
doDebug variable within a template to turn debugging on or off and that
setting will propagate to the descendant templates.
This approach is working well to make it easier for me to control my
debugging dynamically and more easily focus my messaging. But it adds some
overhead to the code in that you need the debug parameter and with-param
everywhere, which isn't that big of a deal to add but still.
My question: is there a better way to do this? Am I overlooking some
feature of XSLT 2 (or 3) that would make managing debugging messages
easier? Should I step up to a more complete messaging framework that
mirrors e.g., log4j?
This is in the context of quite complex transforms with multiple phases,
lots of twisty logic, non-obvious stuff, and so on, as opposed to workaday
HTML- and FO-generation transforms, for which this level of sophistication
is not usually required.
Thanks,
Eliot
----------
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--