|
Hi Dane
It appears JTidy's DOM implementation returns null
for getLocalName() which is causing this problem (unlike the other DOM's the
JUnit unit tests run against).
The problem has only just come to light due to some
refactoring of DOMReader that occurred in 0.5. It was a one line fix to work
around this issue and I've checked the fix into CVS. You can download the daily
build to fix this issue.
I've added both a JTidyDemo sample program to the
samples area (src/samples/JTidyDemo) to show how to load a dom4j Document from a
HTML document as well as adding JTidy into the TestRoundTrip JUnit tests - so
from now on parsing a HTML document with JUnit then round tripping to dom4j
-> text -> SAX -> DOM -> dom4j will be unit tested, so this problem
should never come back again.
Thanks for finding this issue Dane!
James
----- Original Message -----
Sent: Thursday, June 21, 2001 10:31
PM
Subject: [dom4j-user] DOMReader
problem
Hello all. I just downloaded and changed my classpath to
reflect the
dom4j-0.5 build. Shortly thereafter my app began to miss
behave. I changed
by classpath back to the 0.4 build and re-ran my
app and it worked. I think
I've narrowed the problem down to the
DOMReader class.
I'm using JTidy to clean up and convert a HTML
document to an XHTML
document. The XHTML document is then passed to
the DOMReader class to be
converted to a dom4j document. The new
version of dom4j is choking on the
XHTML document. To verify this, I
had JTidy write out the converted
document to a file (see attached) then I
had dom4j write out it's copy of
the document after the conversion (both
0.4 and 0.5). The 0.4 print out is
almost identical to the JTidy
print out but the 0.5 print out is completely
screwed up.
I've
attached the html filez.
I know a possible work-around would be to
have JTidy write the file out then
have dom4j parse back the xml
stream. Is this the best way to go?
Thanx
Dane
Foster
Equity Technology Group,
Inc
http://www.equitytg.com.
954.360.9800
|
