[jdom-interest] building jdom trees

[Richard Cook]

OK what I did for my particular requirements was to make SAXHandler public
and add a SAXBuilder constructor that takes a SAXHandler (perhaps this is
too specific for general work), then wherever SAXHandler calls new Element()
or new Attribute() it instead calls a template method createElement() or
createAttribute() which defaults to return new Element()/Attribute(), so a
subclass can override these and still get most of the SAXHandler
functionality; I can't see why it won't work but i havent even compiled it
yet let alone test it.




-----Original Message-----
From: jdom-interest-admin at jdom.org
[mailto:jdom-interest-admin at jdom.org]On Behalf Of GB/DEV - Philip Nelson
Sent: Wednesday, March 07, 2001 6:20 PM
To: Jdom-Interest at Jdom. Org
Subject: RE: [jdom-interest] building jdom trees



> Probably a silly question, but SAXHandler creates Element
> objects directly
> via new, so is it not possible to build a JDOM tree which
> contains Element
> subclasses? Do I have to build the JDom tree then create some
> sort of clone
> which adapts each Element to the interface I need?
>

I agree with you that it should be possible to use a subclass of SaxHandler
from SaxBuilder.  I seem to remember Jason agreeing with that point not so
long ago.  With a SaxHandler subclass, you could easily integrate your own
Element, Attribute subclasses though the effort would still end up
re-implementing significant numbers of methods.

So far I have used an approach something like (but not exactly like) the
Decorator pattern

Element enhancedElement =  new MySubclass(originalElement);

It can work via delegation most of the time, but that means a lot of coding.
As more pieces of Element become Protected, this may be a little easier to
do but riskier I suppose.  It has only worked for simple behaviour changes
though and I don't think it would be a viable option most of the time unless
Element itself was designed as a decorator.

>
> Also Element::equals(Object) is final and uses "==", which
> means I can't
> change it; this is presumably a necessity I shouldn't change?
>
Search the list, it has been discussed fairly often, though I don't remember
the discussion ;^(

> I have a tendency to write element.getChildren().get(i) and
> suchlike, I
> notice that getChildren() builds a PartialList each time so
> obviously this
> is inefficient (actually I guess LinkedList.get(i) also loops
> and I should
> use an iterator?); is there a set of performance hints anywhere?

I think this feature is a nice feature of JDOM.  I've just started to do a
little profiling and this has not jumped out at me so far, but I wasn't
looking for that either.

What has jumped out at me though is how often we use String.equals but that
is a different story.
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com