Re:[xslt] debugger callbacks

Have you set xslDebugStatus to something other than XSLT_DEBUG_NONE, see 
<libxslt/xsltutils.h>.  You may find you can get the information that you 
want using xsldbg :-). 

Known cavates for the debugger callback functions are:
	o Be careful if you are modifing the data XSLT engine data structures  during 
a debugging step as you could put the tranformation engine into a bad state 
and give misleading resuilts.  
	o Be aware that the callbacks may not be in the same order as you would read 
the text source for the XSLT script.  
	o The XSLT pre-processing step will remove certain redundant  nodes, such as 
comment nodes, from the XSLT script before main work of  XSLT transformation 
is done. 
	o Line number information may or may not be available for any given XmlNode 
due to optimizations done during the pre-processing step
	o Whilst the xslAddCall and xslDropCall are always done in pairs the call 
stack depth can get over stated.  This is because transformation of some XSLT 
commands, for example xsl:for-each, increase the call stack depth otherwise 
there would be no way to know how to "break  out"  of the for loop. 


Daniel: Maybe these cavates could be added to the libxslt FAQ. I had trouble 
when I did  a search on xslDebugStatus in the XSLT API.  And I was suprised 
to get a "Error 404"  when pointing my browser at
as suggested by the "xslHandleDebugger" link resulting from pointing my 
browser at
(URL tested on Mozilla and Konqueror). 

Kasimier wrote;
> I tried to use xsltSetDebuggerCallbacks to get some callbacks during the=20
> transformation, but the registered functions are not called. Since a=20
> call of xslAddCall, fires the registered callback, I assume that=20
> xsltDebuggerCurrentCallbacks is correctly initialized.
> I guess libxslt (version see below) was compiled with WITH_DEBUGGER.

Keith  Isdale  |   xsldbg helping understand 

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]