[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [wtp-incubator-dev] Smoke Test Time
|
DOUG SATCHWELL wrote:
Please bear with me on this. It has got nothing to do with the Saxon
debugger - I have deleted this code from CVS.
*without the Saxon plugin, the user cannot add Saxon processor instances*
The Saxon plugin contributes the Saxon processor _type_. NOT the
Saxon processor itself. The user adds this himself via the preferences.
Please, just try out the code a) with the Saxon plugin installed and
b) without it. Try adding processor instances via the preferences. Add
a Xalan one, and a Saxon one. I think after playing with it for a
while you will understand what I am trying to say (email is so
frustrating sometimes!).
Doug, I see what you are saying, and I think that particular
functionality needs to be reworked. I personally don't think that a
person should have to pre-define a processor type in order to add an
available processor. I think you might be able to get by with making
it more generic. Something like:
1. Java Processor
2. Command Line
Or something else. Regardless, I do like the extension point for
adopters to use to provide specific functionality for their specific
processors, but Saxon we have to avoid for now. That functionality
along with the debugger extensions needed by it, should come from Saxon
or an Adopter of XSLT Tooling.
If we allow saxon, then we have to allow Sabletron for Perl, LibXSLT for
PHP/C, Xalan C++ for CDT, etc. It's a slope I'd rather stay away from,
and encourage adopters to add the necessary support, or rewrite the way
it is currently implemented to give the user more control with out
having to pre-define Processor Types.
Dave
