[jdom-interest] Some add-ons to JDOM
Joseph Bowbeer
jozart at csi.com
Mon Feb 12 18:34:42 PST 2001
Question: Can you explain how the callback mechanism you added is different
from the XMLFilter that can be applied to the SAXBuilder?
Suggestion: It would be more efficient to implement your context grouping
using HashMap instead of Hashtable (no synchs).
Confusion: I don't follow your comment about testing for root element and/or
null document, or the subsequent comment about using list operations as the
basis for document maintenance. Can you elaborate?
----- original message -----
From: "de Grijs, Rudolf" <Rudolf.de_Grijs at softwareag.com>
To: "'jdom-interest at jdom.org'" <jdom-interest at jdom.org>
Date: Mon, 12 Feb 2001 23:55:20 +0100
Subject: [jdom-interest] Some add-ons to JDOM
[ ... ]
But we found out that a few things were missing with JDOM (version b5):
First of all we would like to be able to filter the result document. So I
dived into the source and I was able to implement an efficient callback
mechanism that's called during the build of the document (using the SAX
parser). We need this feature since the documents are multi-lingual, e.g.
<component>H2O2
<characteristics>
<explosion_info language='nl'>....</explosion_info>
<explosion_info language='en'>....</explosion_info>
<explosion_info language='fr'>....</explosion_info>
</characteristics>
</components>
Well you get the picture. If the customer wants to print a Safety Material
Data Sheet he must be able to print it in the language of his choice. Using
a Filter enables us to filter the result document during the build phase.
Another wish (which is high on the wishlist I assume) is the ability to
query the result document with XPath. I had a look at the work done so far,
but I was not able to get it working, so I made a fresh (and more
importantly) and simple start:
Beside the use of the container (LinkedList) content, which is used to hold
the content of an element, I'm using a Hashtable to group the elements using
their context as key. It's just another way of grouping elements according
to their context. This should make it easier and more efficient to implement
XPath.
Though it's not complete we are using it at the moment to search the (large)
Safety Material Data Sheet documents. Furthermore I had to make a few minor
adjustments to Element, e.g.
document is not null when an element is part of a document (detecting if a
Element is the root should be done as follows * (document != null && parent
== null) * instead of * (document != null) *
Furthermore I don't think it's good practice to allow list operations as the
basis for document maintenance, since you're breaking the implementation.
E.g. if I want to add different axes using different containers. Within the
methods addContent and removeContent I'm able to synchronize all used
structures. So as far as I'm concerned they are revived from their
deprecated status.
I have never contributed anything to the community so far, so could someone
tell me how to proceed (if it's of any use)?
More information about the jdom-interest
mailing list