Community
Participate
Working Groups
When debugging an XSLT it is helpful to have a view of the result document as it is being debugged. It would be nice if this had both a preview and source views with it. This way when debugging XHTML/HTML transformations the results code be seen in both web mode as well as source.
Doug adding you to this and putting plan in the keywords. The idea here, is to have a view that is updated as it is stepped through, not just at the end of the transformation. This is very useful for seeing exactly what the output from the transformation is as you step through the code.
Mass Migration to wtp.inc.xsl
*** Bug 239055 has been marked as a duplicate of this bug. ***
Doug how difficult would this be to implement. I know that this is the one big item for me in trying to use the debugger that we have now. A lot of times I can see what the issue is as I step through and the output is generated. It doesn't have to open in the xml editor, just a standard view that outputs a formatted (if xsl:output indent="yes" is set).
It just needs a bit of thought as to the best approach w.r.t possible large output files. Basically, there are 2 ways to approach it: 1) Listen to all 'generate' events, and build them into one large in-memory StringBuffer. When a breakpoint is hit, send this String to Eclipse through the port that communicates with the debug process. Then clear the StringBuffer, and build it up until we hit the next breakpoint. 2) Listen to all 'generate' events, and write them to a FileBuffer. When a breakpoint is hit, flush the buffer and then tell Eclipse the location of the file. Eclipse can then read the file and render it. 3) Open another port and stream all 'generate' events directly to Eclipse (perhaps buffering a little, and maybe blocking on each send to ensure Eclipse doesn't get too far behind?). I haven't done any investigation on either one, but I'm assuming that Approach 1 will be faster than 2, but that 2 will obviously be more robust since it won't fall over if the output is very large. 3 may be both fast and low-memory, but is probably the trickiest to implement.
This has now been added.
Marking as Noteworthy.
