> This is kind of why when I wanted similar functionality I
> added SAXHandler
> param. to SAXBuilder constructors, and template
> createElement()/Attribute()
> methods to SAXHandler.
The absolutely simplest thing I can can think of is to just provide and
alternative SAXHandler subclass name in the SAXBuilder constructor. If
SAXBuilder sees it, it instantiates it cast as a SAXHandler. For every need
to use custom elements I have thought of, this would suffice. Override one
or two methods and viola, custom JDOM elements. When this doesn't suffice,
you can subclass SAXBuilder now and do whatever you want.
The only obvious problem I can think of (OK it's probably not the only
problem) is that because SAXHandler is package protected, you would have to
create your subclass in the org.jdom.input package. I know there were
reasons for that, probably thinking that SAXHandler is an implementation
detail, but it seems to me that this approach is very easy to implement.
For JDOM it's another constructor and a few lines of code. In most cases,
for a developer where you just want to customize a few pieces of JDOM
elements, attributes etc., its very easy. If a developer wants to do a more
drastic overhaul, no problem, you can override all of SAXHandler, or build
with your own builder. The last one is tougher though because you need to
know a *lot* about xml and jdom to make it work.
So, what have I missed ;^)