XSLT Debugger should show where error occurred when terminat

Are you missing a feature? Request it's implementation here.
jokester01au
Posts: 64
Joined: Tue May 17, 2005 9:16 am

XSLT Debugger should show where error occurred when terminat

Post by jokester01au » Wed Aug 01, 2007 3:59 am

When the XSLT debugger quits part-way through a transformation, the only feedback given is a problem tag. This is good, but when using multiple included stylesheets it is very time-consuming to locate this tag. This is because at the moment validation across multiple stylesheets is not supported and so this situation always has lots of incorrectly labelled errors.

A simple improvement would be to cause the editor to jump to the last-executed instruction when it terminates due to error. This would greatly speed identification of what is wrong.

Regards,
Joe.

sorin_ristache
Posts: 4144
Joined: Fri Mar 28, 2003 2:12 pm

Post by sorin_ristache » Mon Aug 13, 2007 4:40 pm

Hello,

Validation across multiple stylesheets is supported. It is done with a validation scenario which must specify the master XSLT file which includes / imports the other ones and is applied to the current XSLT file when the Validate Document action is executed and the scenario is associated to this XSLT file. Of course it makes sense only if the current XSLT file is one of the files included or imported directly or indirectly by the master XSLT file specified in the scenario.

Do you mean that the problem tag does not contain a location specified by file name and line number? Does it contain a message from the stylesheet, for example sent through an xsl:message element? Is it a message from the transformer engine? Can you give an example of problem tag and a sample stylesheet that generates it?


Regards,
Sorin

jokester01au
Posts: 64
Joined: Tue May 17, 2005 9:16 am

Post by jokester01au » Tue Aug 14, 2007 2:31 am

Validation across multiple stylesheets is supported.
:oops: Thanks for letting me know about this. It will resolve no end of hassles for me.
Do you mean that the problem tag does not contain a location specified by file name and line number?
No, my problem (now partially solved) was finding the problem tag in the first place. Even though the validation scenario will mean that the problem tag is now easy to find, I still think that it would be even better if the editor is to change focus to the last line of XSLT executed before terminating with an error.

For that matter it would be good to do the same in the XML as well.

So, what I am suggesting is that if the XSLT debugger terminates abnormally, it should move the selection to the line of XSLT code that caused the termination, as well as the line of XML that was being processed at the time.

sorin_ristache
Posts: 4144
Joined: Fri Mar 28, 2003 2:12 pm

Post by sorin_ristache » Tue Aug 14, 2007 5:56 pm

jokester01au wrote:So, what I am suggesting is that if the XSLT debugger terminates abnormally, it should move the selection to the line of XSLT code that caused the termination, as well as the line of XML that was being processed at the time.
Thank you for the suggestion. It will be implemented in a future version.


Regards,
Sorin

Post Reply