Ken Rune Helland
kenh at csc.no
Tue Mar 6 07:55:14 PST 2001
I'm using JDOM in a project for reading and modifying XML documents,
and i find it mutch more intuitive than DOM.
I did commen upon this a litle while ago but her goes again.
There have been som metioning of cases where people have for some
reason desided to subclass JDOM classes. I tink we have established
the use cases for this, there are need for functionality that is to
spesialised to make everyone suffer the cost of implementing it
directly in the genral JDOM classes. Some metioned they wanted
to implement a listener model for changes, I just want to add
some fields and some recursive metods that operates on these.
So there is two point's I'd like to raise.
The clonable classes shoud use super.clone()
instead of using new when implementing clone(). This
will allow sublclasses to call super.clone() and
not have to duplicate the functionality of the super class.
For example now when i subclass Element I have to duplicate
the code in Element.clone() and then write the part needed
for the fields of my own subclass.
Instead my subclass clone could have been as easy as:
public void clone()
MicsElement element = (MicsElement) super.clone()
// here woud handle the cloning of the MicsElement fields,
// but since all are references to immutable objects or
// primitive datatypes dont have to do anyting sinse Object.clone()
// makes a byte for byte copy.
// But to demostrate i have inserted an example
if( this.foobar != null ) element.foobar = (Foobar) this.foobar.clone();
( MicsElement is my Element Subclass )
If some bug is discovered or someting else changes
in the Element.clone() I woud automaticaly be updated
and not have to copy the changes to MicsElement.clone()
And if someone need to subclass MicsElement they could also implement
clone this way and not have to duplicate the functionality of both
Element and MicsElement.
I'd like also to metion that AFAIK this is the recomended way to
implement clone and also the way it is done in the clonable classes
in the java.* packages: LinkedList, Vector, Date, HashTable and
all others I have checked.
The changes need are small and wont affekt the API other
than for the subclassing.
I'm willing to do this change and post it if there is accsept
for it in the JDOM prosject.
So, I have subclassed one or more of the JDOM classes but that
is useless if i cant get the builder to use them.
I have looked att the saxBuilder and it is not hard to make it
use my class, but still it woud be my own copy of the builder
source and i woud not be able to take easy advantage of
bugfixes or other improvements to the builder.
So i woud advocate that the builders has an option to set a
factory for the classes. Of cource there woud be a default
factory using the standard JDOM classes.
The only drawback I can see from doing this is that the users
using the standard JDOM classes woud get an exstra overhead of
one function call for each object created.
or one can have no default factory and use:
if( factory == null)
element = new Element(localName, elementNamespace);
element = factory.element(localName, elementNamespace);
witch woud give the exstra overhead of a if statment.
This way as builders are improved or builders from new sources are added
the "subclassers" will be able to take advantage of this easily.
More information about the jdom-interest