RE: Problems with Tracing

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: Problems with Tracing

Michael Kay
You're right that attributes of literal result elements in XSLT aren't being notified to the TraceListener. I will fix this. They will in future be notified with construct type Location.LITERAL_RESULT_ATTRIBUTE, a constant which was intended for that purpose.
 
As far as I can see the local variable is being notified to your TraceListener but your TraceListener is not doing anything with the information. You have some code in there which successfully detects it as Location.LET_EXPRESSION and then does nothing with it.
 
When you say you want paths to the nodes, are you referring here to nodes in the stylesheet? This is actually more feasible now than it was, because when tracing is enabled the stylesheet tree is actually retained in memory at run-time, which was not the case at one time. In fact, you already seem to be doing this with the following code:
 
if(instruction instanceof StyleElement) {
        StyleElement styleElement = (StyleElement) instruction;
        _scriptPath = Navigator.getPath(styleElement);
      }
 
So I'm not sure what change you are asking for here.
 
I would rather that discussions like this are carried out on the saxon-help list - it enables other users to butt in with suggestions, and to get advance notice of forthcoming changes. I have therefore copied the response to the list.
 
Michael Kay


From: Marc Pellmann [mailto:[hidden email]]
Sent: 14 December 2005 10:57
To: [hidden email]
Subject: Problems with Tracing

Hi Mike!

We have emailed a while before about this. We use your great Saxon to trace/debug XSLT code and I have some problems with this. I get no informations on variables and on attributes.

I have added my TraceListener implementation with a main method that could be called to this email. The source and the script are as string objects in it for testing. (There is a second helper class, that is used, too).

It would be great, if I could get informations for all nodes in the script and in the source at execution time. And what I realy needed are the unique xpaths of this nodes to show them in the UI.

But you have stated out before, that this is difficult!?

In the "badScript" of the main method are the
attribute von="{Order/Person}", that generates no trace and the
variable <xsl:variable name="test" select="Order/Title"/>, that does not generate a trace, too.
-- 
Viele Grüße / best regards

Marc Pellmann - System Architect
_______________________________
inubit - integrating your business and IT
inubit AG
Lützowstraße 105-106
D-10785 Berlin
Fon: +49.30. 72 61 12-132
Fax: +49.30. 72 61 12-100
Freecall: 0800-go inubit
Web: www.inubit.com
Reply | Threaded
Open this post in threaded view
|

Re: RE: Problems with Tracing

Marc Pellmann
Hi Mike!
You're right that attributes of literal result elements in XSLT aren't being notified to the TraceListener. I will fix this. They will in future be notified with construct type Location.LITERAL_RESULT_ATTRIBUTE, a constant which was intended for that purpose.
Thank you!
As far as I can see the local variable is being notified to your TraceListener but your TraceListener is not doing anything with the information. You have some code in there which successfully detects it as Location.LET_EXPRESSION and then does nothing with it.
Yes, but I do not get the right information about the source path. If I call this

        /* get the xpath of the source node */
        Item item = context.getContextItem();
        if(item instanceof NodeInfo) {
          NodeInfo nodeInfo = (NodeInfo) item;
          _sourcePath = Navigator.getPath(nodeInfo);
        }

I get "/" in _sourcePath, but the Node, that is realy visited in the given example is "/Order/Title"
When you say you want paths to the nodes, are you referring here to nodes in the stylesheet? This is actually more feasible now than it was, because when tracing is enabled the stylesheet tree is actually retained in memory at run-time, which was not the case at one time. In fact, you already seem to be doing this with the following code:
I have had problems with some paths. I will test this and post the special case, where it happens.
-- 
Viele Grüße / best regards

Marc Pellmann - System Architect
_______________________________
inubit - integrating your business and IT
inubit AG
Lützowstraße 105-106
D-10785 Berlin
Fon: +49.30. 72 61 12-132
Fax: +49.30. 72 61 12-100
Freecall: 0800-go inubit
Web: www.inubit.com
Reply | Threaded
Open this post in threaded view
|

RE: RE: Problems with Tracing

Michael Kay
As far as I can see the local variable is being notified to your TraceListener but your TraceListener is not doing anything with the information. You have some code in there which successfully detects it as Location.LET_EXPRESSION and then does nothing with it.
Yes, but I do not get the right information about the source path. If I call this

        /* get the xpath of the source node */
        Item item = context.getContextItem();
        if(item instanceof NodeInfo) {
          NodeInfo nodeInfo = (NodeInfo) item;
          _sourcePath = Navigator.getPath(nodeInfo);
        } 
 
The context item is "/" because you are in a template that specifies match="/", and the select expression of the xsl:variable is executed with "/" as the context node.  

I get "/" in _sourcePath, but the Node, that is realy visited in the given example is "/Order/Title" 
 
The expression /Order/Title is evaluated, but it doesn't become the context node, it becomes the value of the variable. Saxon doesn't actually notify the value of the variable to the TraceListener - apart from anything else, it usually isn't evaluated immediately, but only when the value is actually needed, and the evaluation is often incremental. You can get the current values of variables by calling the getStackFrame() method on the context object.
I have had problems with some paths. I will test this and post the special case, where it happens. 
 
I noticed that your code is doing some strange things with paths, for example it is concatenating the result of Navigator.getPath() with the actual select expression used in a for-each. That doesn't make much sense if the select expression is something like "$x".
 
Michael Kay
-- 
Viele Grüße / best regards

Marc Pellmann - System Architect
_______________________________
inubit - integrating your business and IT
inubit AG
Lützowstraße 105-106
D-10785 Berlin
Fon: +49.30. 72 61 12-132
Fax: +49.30. 72 61 12-100
Freecall: 0800-go inubit
Web: www.inubit.com