| Re: [wtp-incubator-dev] XSLT Debugging |
DOUG SATCHWELL wrote:
I'm not really interested in doing that - its taken alot of work to get debugging to where it is! You are welcome to have a look at doing that yourself though, if you can see lots of benefit in doing it.
Doug,I've been doing some prototype testing with the DLTK Launch and Debug configurations. Surprisingly, the setup is pretty close to the way we have the current XSL Configuration. Here is some information on what I have figured out.
Everything in DLTK Launching is based on Interpreter configuration. Whether that be interpreters for Ruby, TCL, Python, Jython, Perl, or any other dynamic language. We currently are focusing on a very specific interpreter being XSL and then getting more specific from that point. What they call an interpreter, we call a Processor. An interpreter can have a Launch Configuration and a Debugger. The debugger is optional, and if a launch configuration is launched in debug mode for an interpreter that doesn't have one it will toss an exception and won't let it run (the exception is caught and a user friendly dialog is shown).
Every interpreter has a Preference setup page, the setup page is very similar to the XSL Java Processor pages. As it lets one add specific Interpreters. For Ruby, it allows specify Ruby interpreters to be added. A user can add specific Debuggers for the interpretes...Jruby, Basic Ruby Debugger, etc. In some ways this is similar to Adding a new XSL Processor. Xalan, Saxon XSLT 1.0, Saxon XSLT 2.0, etc. However, I would think if we adopted their methodology for creating an interperter we would have a JAXP interperter, and then allow for adding of Xalan, Saxon XSLT 1.0, Saxon XSLT 2.0, or another JAXP interpreter like Oracle's.
By adopting the Intepreter framework, we would have a way to add support for non-java interpreters. Like Microsoft's .Net interpreter, GNOME's XSLTProc, Sabltron, or any other command line based interpreter. We had mentioned possibly having a separate launch configuration for non-java interperters anyways. This would allow a way for an Adopter to use the DLTK framework to setup the necessary launch configuration for the External configuration.
What this then allows to happen is that we can leverage your existing debugging framework, and interface it into the the DLTK debugger and launcher. This way we inherit the ability to setup Watch expressions, Hovers for variables, and other features the DLTK debugger already provides. For launching the Java specific processors, we can still leverage the work that you have already done, but would need to do some slight modification to the debugging interfaces (I've already started some of this work to see if it would be feasible, and it isn't that difficult to get setup).
There still would need to be some additional views like the Result View that I know you are starting to work on, as well as adding the specific understanding of Nodesets for the variables. There are examples from the Ruby interpreter that show how this is done (I've got a basic start on this).
I'm going to continue tweaking the current code for a possible migration to DLTK. I just need to rework the preference pages on the Java Processors so that we can leverage more of the built in support of the DLTK framework.
In the long run, I think it will help solve some of our problems with supporting non-java processors for launching and debugging support (if any of them have it).
Anyways, that is what I've found so far, once I've got an implementation working, I'll provide a patch file for review.
Dave