Re: how to get the line number of the context node?

[Ovidiu Predescu <ov...@cup.hp.com>]

On Tue, 15 May 2001 20:09:56 -0400, Scott_Boag@lotus.com wrote:

> What people are doing is subclassing an implementation of a DOM for that
> purpose.  We might make something like this optional, but I don't want to
> store the line number in most cases.

Either this or keep the line number information in a separate
hashtable, as Brian Quinlan suggested in an earlier email. I think
this functionality is very useful not only in editors, but also for
automatically generating code from XML documents. JSP and Cocoon's XSP
or sitemap are the best examples, in case of errors one can refer back
to the XML source if line information is present in the generated
code.

Brian, can post your patch on the mailing list so we can review it?

Thanks,
-- 
Ovidiu Predescu <ov...@cup.hp.com>
http://orion.nsr.hp.com/ (inside HP's firewall only)
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

RE: how to get the line number of the context node?

[Brian Quinlan <Br...@ActiveState.com>]

>> What people are doing is subclassing an implementation of a DOM for that
>> purpose.  We might make something like this optional, but I don't want to
>> store the line number in most cases.

I am not sure what the actual mechanics of this would be. How would I hook
into the DOM such that I could still generate line numbers if the stylesheet
loads a new source document through the document() function?

If it is possible, I would definately consider doing it this way. I am
trying to keep my changes to Xalan to a minimum!

> Either this or keep the line number information in a separate
> hashtable, as Brian Quinlan suggested in an earlier email.
>
> I think
> this functionality is very useful not only in editors, but also for
> automatically generating code from XML documents. JSP and Cocoon's XSP
> or sitemap are the best examples, in case of errors one can refer back
> to the XML source if line information is present in the generated
> code.
>
> Brian, can post your patch on the mailing list so we can review it?

Sure. There are 4 files attached:

XalanSourceTreeParserLiasonEx.hpp
XalanSourceTreeParserLiasonEx.cpp - Knows how to keep the map around

XalanSourceTreeContentHandler.hpp
XalanSourceTreeContentHandler.cpp - Builds a vector of XalanNode *,
ExtendedNodeInfo pairs

XalanSourceTreeContentHandler does it's job primarily by hooking into
doAppendChildNode. I use a separate map and vector to store the line number
information because I was having STL problems and didn't have time to
resolve them.

Also, I have plans to change this in the future so that the line number
collected will be for the start of the event rather than at the end. And
there seems to be a bug collecting the line numbers of comment nodes.

To provide some context for these changes, I work for ActiveState and
ActiveState currently has two XSLT products in beta. They are both IDE
extensions that offer XSLT syntax checking, intellisense and debugging. One
if for Komodo, our own IDE, and the other is for Visual Studio .NET. Both
use a modified Xalan engine for XSLT execution/debugging (1).

The Komodo Windows beta is available at (release will be in about two weeks,
the linux version will be done whenever I am done porting the XSLT stuff
:-) ):

http://aspn.activestate.com/ASPN/Downloads/Komodo/KomodoBeta

The Visual Studio .NET beta is available at (you need VS .NET to use it):

http://aspn.activestate.com/ASPN/Downloads/VisualXSLT/

We would love to contibute our changes back to the community but they have
performance implications and have, therefore, been rejected to date (though
it is probably our fault for presenting them singly and not ifdefing them to
prevent performance problems if they are not used). Some of the changes
involve:

- making the variable stack modifyable and inspectable for debugging
- keeping unparsed template match attributes around so we can present a
stack frame

In the future we will probably have to make changes to the StylesheetHandler
to keep the entire line range of elements around (so breakpoints will work
correctly if the element spans multiple lines).

Anyway, sorry for boring you with my life's story :-)

Cheers,
Brian


(1) The debugger features a variable viewer, a stack frame viewer,
simultaneous tracing through the source and stylesheet documents, source and
stylesheet breakpoints, a watch window that can evaluate arbitrary xpaths at
any stack level, ability to trace through remote documents, etc.