There are indeed languages where these subtle traps happen more
frequently than with others. I remember when I started coding C++ in
1995, there were really frustrating moments. When I started using Java,
these frustrating moments dramatically decreased, and this is not solely
attributable to my overall programming skills that have developed in the
meantime. I found that although Java code is sometimes very verbose and
inelegant (as opposed to Ruby), there are few bonehead or subtle but
undiscoverable mistakes to be made.
XSLT is sometimes verbose (in a different way than Java, but anyway) and
prone to sublte traps (like C++), but you can code quite elegantly (like
Ruby; or rather, if you ever tried Ruby’s XML processing facilities,
XSLT is as elegant as only XSLT is when it comes to processing XML).
Experience will help discover or avoid the traps quickly. Experience
will particularly tell you that a resolute debugging strategy is
indispensable. I didn’t find XSLT’s learning curve to be steeper than
other languages’. The messages I get from the processor/compiler are
quite useful for debugging purposes. (The latter is true only for XSLT 2+.)
I once assembled a list of questions to ask yourself if a template
obviously didn’t match:
http://www.biglist.com/lists/lists.mulberrytech.com/xsl-list/archives/201001/msg00257.html
Is there a Wiki around so that we can collect our wisdom in it?
Gerrit
On 28.12.2010 23:35, David Sewell 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
--
Gerrit Imsieke
Geschäftsführer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
gerrit(_dot_)imsieke(_at_)le-tex(_dot_)de, http://www.le-tex.de
Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930
Geschäftsführer: Gerrit Imsieke, Svea Jelonek,
Thomas Schmidt, Dr. Reinhard Vöckler
--~------------------------------------------------------------------
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>
--~--