Subject: Re: [xsl] Avoiding boneheaded mistakes in XSLT? From: Dimitre Novatchev <dnovatchev@xxxxxxxxx> Date: Tue, 28 Dec 2010 16:18:43 -0800 |
> Do these sound familiar? Other favorite traps? I think that one of the most common and difficult (at times with almost unexplainable behavior) problem is the failure to provide templates match certain nodes. A good solution is to provide a "catch-all" template, for example: <xsl:template match="*" priority="-20"> <xsl:message> ERROR: Unmatched element: <xsl:value-of select="name()"/> <xsl:message> </xsl:template> This signals explicitly in any case when the node-list of an <apply-templates> instruction contains an element that isn't matched by a more specific template. -- Cheers, Dimitre Novatchev --------------------------------------- Truly great madness cannot be achieved without significant intelligence. --------------------------------------- To invent, you need a good imagination and a pile of junk ------------------------------------- Never fight an inanimate object ------------------------------------- You've achieved success in your field when you don't know whether what you're doing is work or play ------------------------------------- Facts do not cease to exist because they are ignored. On Tue, Dec 28, 2010 at 2:35 PM, David Sewell <dsewell@xxxxxxxxxxxx> wrote: > This is to some extent a general programming question, as it is possible > with any programming language to write something that is syntactically > legitimate (i.e., does not throw a compile- or run-time error) but fails > to produce expected results because of a mistake in logic or something > else. I'm sure we've all had the experience of beating our heads against > a programming failure that turns out to be the result of a very simple > (aka "boneheaded") mistake that seems obvious when found. It seems to me > that this is perhaps more likely with XSLT/XPath than some other > environments, because of (1) the general verbosity of expression, and > (2) the many complexities of return values when you're working with a > combination of XML documents and fragments, and sequences of nodes > and/or atomic values. > > Over the last few days I've been working on some especially complex > transforms and have lost more time that I'd like owing to some of these > simple mistakes. Not the first time by a long shot I've made them, either. For > example: > > 1. In an XPath expression, using "something/node" where I wanted > "something/node()" [ditto text vs. text()]: always means zero results and > can drive you crazy if you don't notice the missing parentheses; > > 2. Using xsl:copy-of instead of xsl:apply-templates in a case where > recursive processing is in fact needed on the item in question; > > 3. Using xsl:value-of when you really need xsl:copy-of for a variable > that is a sequence; > > 4. Bad logic with xsl:analyze-string, putting processing into > xsl:non-matching-substring that should have gone into > xsl:matching-substring or vice versa. > > Do these sound familiar? Other favorite traps? > > Has anyone come up with a useful list of "things to check any time my > code is not working the way it should"? > > DS > > > -- > David Sewell, Editorial and Technical Manager > ROTUNDA, The University of Virginia Press > PO Box 400314, Charlottesville, VA 22904-4314 USA > Email: dsewell@xxxxxxxxxxxx B Tel: +1 434 924 9973 > Web: http://rotunda.upress.virginia.edu/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Avoiding boneheaded mista, Graydon | Thread | Re: [xsl] Avoiding boneheaded mista, Syd Bauman |
Re: [xsl] Avoiding boneheaded mista, Michael Kay | Date | Re: [xsl] Avoiding boneheaded mista, Dave Pawson |
Month |