[jdom-interest] Some add-ons to JDOM

[de Grijs, Rudolf]

Hi,

I'm new to this list and I would, just like you, contribute to this list to
make JDOM a perfect tool to work with XML documents.

I do know that a lot of people already are working on improving JDOM, but I
would like to share my experience with JDOM with you.

At the moment I'm working on a reasonable large XML project for a customer
of ours. First we used Breeze (Castor falls into the same category, right?)
that enables us to serialize XML documents from and to JavaBeans.

As such it's not such a bad product, but with JDOM we were able to implement
a more flexible framework, since the 'databinding' occurs at runtime (in
contrast to Breeze).

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)? 

Kind regards,
Rudolf de Grijs

senior consultant Software AG Netherlands