[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [wtp-incubator-dev] Breakpoints on XML files
|
Jesper Steen Møller wrote:
DOUG SATCHWELL wrote:
OK - I've added it...but I'm not sure how to make use of it!
Breakpoints on the stylesheet are simple - just listen to trace
events and we are guaranteed to hit every node in the stylesheet and
therefore all breakpoints in the stylesheet.
But trace events are not fired for every node in the _source_
document, so breakpoints on source nodes will frequently be
missed...not sure how to solve this one??
I don't think there is a trivially correct answer to this question,
like there is for template breakpoints, so I guess we'd have to think
about what the user might expect, which I guess is one of several
possibilities:
Q: When is an XML input breakpoint hit?
A1: When the element it represents is the selected node in a template
match or invocation.
Yes. Currently one Eclipse based XSLT editor I use allows for setting
the break point in the XML Input file. As soon as the xslt editor
starts processing that particular node, it breaks on that node if their
is a break point set.
A2: ... or the "current node" in an for-each.
I only would want it to break if the node on the XML file had the break
point. So I don't necessarily want it to break if the parent node is
being looped through, but only when I hit the current node with the
break point.
A3. ... or used in any XPath expression.
Yes. This would be a conditional Expression test. If a break point
matches a certain XPath expression, then it should break but only if the
xpath expression matches.
A3.consequence: Including whenever control/selection is transferrered
into a child of the node
Does this make sense, and is it possible?
All of this is possible. Just for some academic research, I would
suggest taking a look at some of the features of Oxygen XML. It has
built in support for XSLT and XML editing and debugging during
transformations. Now I will say this, it doesn't appear to make use of
the Eclipse debugging framework but it's own framework. So I suspect
that we are going to have to design a lot of this ourselves. It'll
probably mean getting further down into each of the debugging
frameworks, and possibly writing our own interfaces on top of what is
provided so that we get the functionality we need.
Dave