XML Developer TipSweet (debugging) relief from breakpoints
Back in days of yore when I still wrote real code for a living (mostly FORTRAN, some Pascal, and a little DEC CLI to let you know how long ago that was), we always had fun designing tools to help us debug interfaces. That's because a lot of the work that I did was to create function libraries for other people to use in their programs to provide specific kinds of functionality (and believe me, that's really all you want to know).
When you call external functions or libraries, debugging tools can often be an issue. Sometimes, it's hard to tell where the line between "your (custom) code" and "library code" really sits. It's even trickier on some occasions to figure out what happens when your code passes values into a library and when the library passes values back to your code. I formed the habit of writing "instrumentation blocks" around such hand-offs during debugging, because I wanted to see exactly what my test programs were passing into the libraries, and what those libraries were returning.
My memory of those far-from-halcyon days came back with a vengeance recently when I found myself trying to figure out how to separate the effects of my own XSLT statements from the effects of the underlying processor while hacking my way through some markup last week. "I remember this!" I said to myself after beating my head against the way for a while: "I need to instrument my code" after which I had to write more XSLT to display incoming and outgoing values and such. After further thrashing, I started thinking fondly about the DEC debuggers in my old days, which were very good about permitting you to set breakpoints (which report such things automatically, and permit you to step through code to see what's occurring from one step to the next, or jump from point to point as you wish). "Boy, " I said to myself "it sure would be nice if I could set some breakpoints in this markup."
Of course, after a bit more hashing around, I stumbled across a tool called DesignerXSL from United Business Technologies, Inc. where somebody higher up the learning curve apparently not only had the same thought, but acted upon it pretty powerfully. Suffice it to say that DesignerXSL not only supports developer-based breakpoints, but also stepwise processing of style sheets (two wonderful capabilities for those learning their basic syntax and structure, but also for those forced to look for sources of interesting behavior between their own markup and the underlying behavior of an XSL/XML processor). In my case, you could say "I fought the law, and the law won," but you could also say I re-learned an old developer's lesson and put that knowledge to work in a good way. For those involved in serious XSL activity, this tool might be worth digging into more deeply.
About the Author
Ed Tittel is a principal at LANWrights, Inc., a wholly owned subsidiary of LeapIt.com. LANWrights offers training, writing, and consulting services on Internet, networking, and Web topics (including XML and XHTML), plus various IT certifications (Microsoft, Sun/Java, and Prosoft/CIW).
For More Information
- Need help with the latest industry acronyms and terms? Visit our helpful Glossary.
- Visit our Best Web Links for the best editor-selected XML resources on the Web.
- Post your technical questions, or help your peers in our Enterprise Developer Forums.
- Ask the Experts! Our Web Services, SOAP, WSDL, XML, .NET, Java and EAI gurus answer your toughest questions.