[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Avoiding boneheaded mistakes in XSLT?
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 Rubys 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 didnt find XSLTs 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 didnt 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.
Registergericht / Commercial Register: Amtsgericht Leipzig Registernummer / Registration Number: HRB 24930 Geschdftsf|hrer: Gerrit Imsieke, Svea Jelonek, Thomas Schmidt, Dr. Reinhard Vvckler
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|