Community
Participate
Working Groups
Ability to set the break points on a particular node within the XML document used as input to the transformation process. This would allow finer control over large transformations when a particular node is not transforming as expected. Request from the Requirements Page.
The ability is there now, but I'm still not sure how to go about making this work. It is entirely possible to put a breakpoint on a source file that will never get hit, even though the entire contents of the source file were cut and paste into the result document! I don't see any obvious way of getting this to work in Xalan at least.
well, I know it works in some other eclipse based XSLT editors. Is there a way to calculate an XPath break point on the input source, and have Xalan break based on that XPath expression?
I'm not sure how the other debuggers do this. So I've removed the ability to set breakpoints for now (because they don't do anything anyway). Will have another look at this later, unless someone else wants to take a look of course.
Doug, I'll take a look after 0.5M6 is out the door. I think for Xalan, it has to be a specific type of TraceListener value we need to watch for. Possibly something with the input document. I'd also like to look at the DLTK debugger extensions they have, as it might help us with our implementation.
Marking as helpwanted.
Doug, while looking at some of the Xalan code, I ran across a couple of interesting classes that might be of use to you. They are currently marked as being deprecated but were setup for some XSL Tooling use. They are located in the org.apache.xalan.transformer package and are: TransformSnapshotImpl TransformState These two classes seem to give you a lot more information than just the events and node list that were passed. I haven't gone into detail on your debugging code, so you may already know about these classes. In particular what is of interest is the State contains what input node matched the template. So this could be useful in determing the appropriate break point for the XML input file.
Setting as enhancement
Mass Migration to wtp.inc.xsl
*** Bug 221532 has been marked as a duplicate of this bug. ***
I'll investigate for 1.0M4.
Doug, I had another look at this, and for both the XPath and the XML input, I think this particular functionality could be handled by implementing the selected(SelectionEvent event) method in the XalanPrintTraceListener. The SelectionEvent is triggered by a selection of a Node in the StyleTree. http://xml.apache.org/xalan-j/apidocs/org/apache/xalan/trace/SelectionEvent.html It carries with it the result of the selection, the current context node, and the XPath that executed the selection. It seems that it would possibly allow for setting the breakpoints, and just making sure that we stopped at the right node. If I can get some time, I'll look into this some more, but your thoughts would be appreciated since you are more familiar with the way the Xalan debugger works.
TraceEvent passes in the context Node. What could be done is to load the Source file into the WTP DOM, and then run the CalculateXPathtoNode function (which has been migrated to XPathHelper class in org.eclipse.wst.xml.xpath.core plugin), a comparison could be done on the two returned strings. If they are contained in or equal, then and the line number from the source file has a break point, we could then have the break point stop and step through the source code.
(In reply to comment #12) > What could be done is to load the > Source file into the WTP DOM, and then run the CalculateXPathtoNode function The process should be the other way round; we tell the debug process what the break point line numbers and corresponding xpaths are, using the same mechanism we currently use for break points in the XSL file. The debug process itself can then use CalculateXPathtoNode (or rather a copy of that function that is available to the debug process) to determine whether it has hit a breakpoint. That way you don't need to send whole documents over the socket while stepping. I must say though that it all seems a bit awkward compared to setting breakpoints on the XSL file. Not very pretty at all in fact. Surely there is a better way?
(In reply to comment #13) > (In reply to comment #12) > > What could be done is to load the > > Source file into the WTP DOM, and then run the CalculateXPathtoNode function > The process should be the other way round; we tell the debug process what the > break point line numbers and corresponding xpaths are, using the same mechanism > we currently use for break points in the XSL file. The debug process itself can > then use CalculateXPathtoNode (or rather a copy of that function that is > available to the debug process) to determine whether it has hit a breakpoint. > That way you don't need to send whole documents over the socket while stepping. Well, if Xalan is using it's own internal DOM, and just returns a NodeList, you don't necesarrily have a line number. If we can make the Xalan use an WTP DOM and then cast back to an IDOMNode we can get the line number of the Nodes or even the Context Node with out having to do the CalculateXPath. > > I must say though that it all seems a bit awkward compared to setting > breakpoints on the XSL file. Not very pretty at all in fact. Surely there is a > better way? Yeah it's ugly. I'm open to other solutions that might work, but Xalan does pass in the current Context node which comes from the XML file that the template or selection is running against. We just have to figure out a way to match that up with the XML Input file for break point selection. Also the context node can be used to enable Watch Expressions as well based on XPath statements.
not sure if I'm going to have time to fully investigate this so re-assigning back to project in box so that others may pick it up.
*** Bug 266315 has been marked as a duplicate of this bug. ***
mass update to 3.1 target due to movement from wtp incubator to wtp source editing lost the original milestones.
migrating prior 3.1 enhancements for future for further triage and planning.
Assigning inbox items to triaged since these have all be triaged.
