Re: [wtp-incubator-dev] XSLT Debugging

[DOUG SATCHWELL <doug.satchwell@xxxxxxxxxxxxxx>]

At the moment, when someone has a launch config that uses the JRE default, and then they try to debug we have a dialog that pops up to tell the user that there isn't a JRE default debugger, and asks them if they wish to debug using Xalan instead. I want to add a 'do not ask again' check box to that dialog so that it doesn't pop up every time. This would seem to be more or less equivalent to what you suggest - i.e. we already have debugging support out of the box?
The debuggers have to interface with either Saxon or Xalan, there are common parts though - you can see the common code in the jaxp.debug plugin, and the processor-specific code  in the xalan plugin.
We can look at this in more detail once I've committed the refactored code, as with this code there is a way to choose between different interpreters. We'll have to look at whether the DLTK mechanism is better than that one.
BTW - didn't get the screenshot attachment!



----- Original Message ----
From: David Carver <d_a_carver@xxxxxxxxx>
To: WTP Incubator Dev list <wtp-incubator-dev@xxxxxxxxxxx>
Sent: Tuesday, 26 August, 2008 5:35:41 PM
Subject: Re: [wtp-incubator-dev] XSLT Debugging

DOUG SATCHWELL wrote:
> Thats great. Please don't commit any work on this yet though, as I 
> have done a lot of refactoring which I'm going to commit after M1. 
> Then we can look at using the DLTK (though I'm still not entirely sure 
> what it gives us, as everything you mention is already implemented, 
> anyway we'll leave that for another day).
Doug, there are some additional items we could inherit from the DLTK 
framework besides debugging, but I'm not sure how critical they are, and 
really how compatible with the SSE editor they would be.    With this 
said, there is one thing I do like about the debugging framework they 
have setup.  They've broken the concept of the interpreter to be used 
during launch configurations from the concept of the debugger to use.    
In someways this makes sense for us as well, with the exception of using 
Processor specific functionality and trying to debug that.  Here is a 
screen shot of the preferences, sorta XSL Toolized:



The engine concept could be used by XSL Tools to provide a Basic XSL 
Debugging engine that is used by default.  Since we redistribute Xalan 
with the XSL Tools, and we leverage several of the API for editing and 
validation, I think it might be a good idea to have Xalan as the default 
debugger for all XSL Debugging situations.    If a user or adopter wants 
to add a different XSL Debugger to the list, they can do that through 
the existing XSL Tools extension points for the particular processor 
they are contributing.

This allows those users that use the default JRE as their interpreter to 
get some basic debugging support for XSLT 1.0 stylesheets.  If we 
didn't want to go the debugging engine route, then I think an addition 
to the XSL Processor extension point should indicate whether that 
particular processor uses the Default Basic Debugging engine, or whether 
it contributes it's own debugging engine, or doesn't support debugging 
at all.

This would at least give everybody basic debugging support out of the box.

Thoughts?

Dave


_______________________________________________
wtp-incubator-dev mailing list
wtp-incubator-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-incubator-dev