[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Is there any XSLT debugger stepping in subexpressi
No one has mentioned a dedicated XPath-Debugger that I've developed for the last couple of years, perhaps because its not yet integrated with an XSLT environment (though it can auto-import expressions from XSLT, using XPath!). This graphical tool (soon to be replaced by a tool that also integrates with a zip-agnostic multi-threaded batch-XSLT tester) lets the user trace through an XPath expression visually step-by-step, predicate-by-nested/chained predicate. It's not perfect but hopefully falls into the 'better-than-nothing' category. It works with for, if, else, return statements reasonably well. The user just clicks the part of the expression they're interested in, or expands the selection to include 1 or more chained predicates. This tool uses Saxon, but doesn't use the Saxon trace (haven't figured this out from Saxon.NET), instead it builds its own expression tree. It uses this to compute a modified expression (taking into account predicates and instance-variables) for the user-selected sub-expression, and then feeds this 'unseen' to Saxon for re-evaluation, the user then gets a sequence returned in a grid-view, and, if it contains nodes, these are also highlghted in a tree-view and text-view. XSD type-annotations are also listed for all sequence nodes for those users (possibly not many from 20,000 odd downloads) with a Schema-Aware copy of Saxon. Unsurprisingly, the same method used for XPath tracing is also used to provide intellisense in normal editing mode that is hopefully a bit more intelligent than the norm. Externally referenced XPath variables (and their context) are loaded into memory and stored in XML files for reuse, but I can improve on this for XPath 2.1, if its to have 'let' declarations (must read that draft soon). Given that many of the development bugs I came across in my teams main XSLT projects were due to incorrect/untested XPath I'm surprised tools haven't really addressed this. But I do see one problem with improved debuggers, this would encourage use of fewer but more complex XPath expressions within XSLT, this could be difficult for maintenance, but that's up to the user I guess. Phil Fearon On Wed, Dec 16, 2009 at 9:28 PM, Michael Kay <mike@xxxxxxxxxxxx> wrote: >> Does Saxon really provide enough data via its debugging API >> to support such debugging? > > Yes. If you compile the stylesheet with tracing enabled, Saxon wraps a trace > expression around every node in the expression tree, and each one results in > a pair of enter() and leave() calls to the TraceListener. > > The problem of course is that if you exposed this granularity in a debugger, > the steps would be so small as to make single-stepping extremely tedious. So > the debugger has to choose which calls to ignore. I don't know how oXygen > does this. I suspect it's doing the same as the Saxon XSLTTraceListener does > when you use the -T option, which is more-or-less to ignore all events other > than those associated with expressions that are classified as XSLT > instructions. > > At present I can't quite see how it distinguishes between an xsl:if, and > xsl:choose, and an XPath if (perhaps it doesn't). They all produce very > similar code but there may be some provenance information retained to make > error reports more readable. > > Regards, > > Michael Kay > http://www.saxonica.com/ > http://twitter.com/michaelhkay
|
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
|