Hi,
this is a proposal for a dom4j 0.9 enhancement.
I think that the idea of the ElementHandler is pretty good. The problem
is that you can only associate one absolute path to an ElementHandler.
Imagine a document like this :
<h1>
<p>
stuff 1
</p>
<h2>
<p>
stuff 2
</p>
</h2>
</h1>
Let's say you want to do something special with <p> elements. You want
to implement it in a separate ElementHandler, but, as far as I know,
it's not possible to tell dom4j that <p> should be handled whatever the
absolute path is. In this case, you could declare 2 ElementHandlers
(possibly calling the same method) for "/h1/p" and "/h1/h2/p", but this
is ugly (and won't fit in many cases). It would be preferable to declare
a handler for "p", whatever the relative path is.
I started a personal project recently, which seemed to require this
feature. Now, I gave it up because I prefer to hack the DOM directly
(dom4j is very cool for that !). Nevertheless, I finished this
implementation, which, at least, runs the test cases.
The feature is based on a new org.dom4j.io.DispathEntries class. It will
require just a few changes to the org.dom4j.io.DispatchHandler and
org.dom4j.io.SAXReader classes in order to work. The DispatchEntries
class keeps a path/handler pair list, and can determine if a given path
has some compatible handlers. Since the call order of the handlers
(there can now be several ones) is important, I wrote a Comparator which
is used for sorting the ElementHandler list, which is kept ordered. I
decided that absolute paths should be treated before relative paths, but
this can be changed easily through the
org.dom4j.io.DispathEntries.PathsComparator. One can even imagine this
order being configured by the user, but this would probably require
changes to the SAXReader class, and looks like overkill.
You will find my code attached.
My opinion about dom4j : the more I use it, the more I like it. JDOM or
W3C DOM do nothing the way I want. dom4j simply rocks. Thanks for making
good software. Please continue !
DispatchEntries.zip
