Creating a Document from a Node

[pwaring]

I'm trying to use JTidy (latest release version, I can't use the svn
version) to pretty print a Node (org.w3c.dom.Node). However, the only
method for printing nodes in org.w3c.tidy.Tidy is:

public void pprint(org.w3c.dom.Document doc, java.iutputStream out)

So I need to create a Document containing only one node so that I can
pass it as an argument to this method Does anyone know how I can do
this? I've tried a simple cast (which doesn't work), and creating an
empty document then adding a node to it with the following code:

try
{
content.appendChild(currentDiv);
}
catch ( DOMException dome )
{
System.out.println("Error: " + dome.getMessage());
}

However, this throws an exception with the message: "Error: newChild
cannot be a child of this node". Does anyone know how/if I can get
round this? It seems like an awful lot of hassle just to print a Node.

Thanks in advance,

Paul

 

[Tom Anderson]

I'm trying to use JTidy (latest release version, I can't use the svn
version) to pretty print a Node (org.w3c.dom.Node). However, the only
method for printing nodes in org.w3c.tidy.Tidy is:

public void pprint(org.w3c.dom.Document doc, java.iutputStream out)

So I need to create a Document containing only one node so that I can
pass it as an argument to this method Does anyone know how I can do
this? I've tried a simple cast (which doesn't work),

What did the actual class of the Node turn out to be?

and creating an empty document then adding a node to it with the
following code:

try
{
content.appendChild(currentDiv);
}
catch ( DOMException dome )
{
System.out.println("Error: " + dome.getMessage());
}

However, this throws an exception with the message: "Error: newChild
cannot be a child of this node". Does anyone know how/if I can get round
this?

Try Document.adoptNode or importNode, according to whether you want to
remove the Node from the original Document or not.

It seems like an awful lot of hassle just to print a Node.

Welcome to the wonderful world of the W3C DOM!

tom

 

[pwaring]

What did the actual class of the Node turn out to be?

Just a Node (i.e. not a subclass) as far as I could tell.

Try Document.adoptNode or importNode, according to whether you want to
remove the Node from the original Document or not.

I've tried that, with the following code:

Document content = createEmptyDocument();
Node currentDiv = divs.item(i); // divs is just all the <div> nodes
from a document
content.adoptNode(currentDiv);

which results in the following error (at runtime - no problems during
compilation):

java.lang.AbstractMethodError:
org.w3c.tidy.DOMDocumentImpl.adoptNode(Lorg/w3c/dom/NodeLorg/w3c/dom/
Node;

Paul

 

[Tom Anderson]

Just a Node (i.e. not a subclass) as far as I could tell.

Node is an interface. This probably isn't important, but if you wanted to
see what the implementing class was, you could do
someNode.getClass().getName().

I've tried that, with the following code:

Document content = createEmptyDocument();
Node currentDiv = divs.item(i); // divs is just all the <div> nodes from a document
content.adoptNode(currentDiv);

which results in the following error (at runtime - no problems during
compilation):

java.lang.AbstractMethodError:
org.w3c.tidy.DOMDocumentImpl.adoptNode(Lorg/w3c/dom/NodeLorg/w3c/dom/Node;

Well that's not good.

AbstractMethodError usually means there's a library screwup: your code is
fine, but somewhere, there's a class A which thinks class B has an
implementation of some method, while class B declares that method as
abstract. Typically, A and B are in separate JARs, and A was compiled
against a previous version of B, which has since changed to turn a method
from concrete to abstract.

I'd look at Tidy, your XML parser (if any) and any other DOM-related
libraries, and see if (a) the one you think is being loaded really is (by
looking round your classpath etc), (b) they're the versions you think they
are and (c) whether they could or should be more up to date.

tom

 

[pwaring]

Node is an interface. This probably isn't important, but if you wanted to
see what the implementing class was, you could do
someNode.getClass().getName().

It turned out to be org.w3c.tidy.DOMElemImpl, though I don't think
that had anything to do with the problem.

I'd look at Tidy, your XML parser (if any) and any other DOM-related
libraries, and see if (a) the one you think is being loaded really is (by
looking round your classpath etc), (b) they're the versions you think they
are and (c) whether they could or should be more up to date.

I've no idea what's on the classpath when the code executes (it's
a .war file being deployed by Tomcat in the end). In the end I got so
fed up of trying to serialise the Node that I just wrote my own method
to do exactly what I want. Not terribly reusable or clean, but I need
something which works now and I don't have time to debug library
conflicts.

Thanks for the help/pointers,

Paul

 

[Tom Anderson]

I've no idea what's on the classpath when the code executes (it's a .war
file being deployed by Tomcat in the end). In the end I got so fed up of
trying to serialise the Node that I just wrote my own method to do
exactly what I want. Not terribly reusable or clean, but I need
something which works now and I don't have time to debug library
conflicts.

So often the way!

In fact, that's exactly what i'm doing now. I need the Node.getTextContent
method from DOM Level 3, which my current implementations don't support.
So, i've written a version myself, which uses the lower-level DOM methods
to walk the tree and construct the string. Only it turns out that in DOM4J
1.3, which is what i have, if you call getFirstChild() on an Element which
has an attribute, rather than returning an Attribute node, as it should,
or stepping over it, it throws an exception. If i upgrade to DOM4J 1.6, it
works, but then i have to upgrade to the latest Jaxen too, and then loads
of other things break.

AAAAAAAAAAAAAAAAAAAARRRGH!

tom