----- Original Message ----
From: David Carver <d_a_carver@xxxxxxxxx>
To: WTP Incubator Dev list <wtp-incubator-dev@xxxxxxxxxxx>
Sent: Sunday, 24 August, 2008 10:30:51 PM
Subject: 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
_______________________________________________
wtp-incubator-dev mailing list
wtp-incubator-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/wtp-incubator-dev