Re: Managing debug logging in complex transforms: what

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@xxxxxxxxxxxx> 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