[jdom-interest] Important proposal: Element/Document changes

David W. Smiley dsmiley at mitre.org
Tue Jul 25 16:27:09 PDT 2000

The new naming proposal sounds nice in general but:

I think getAttributeText() should exist instead of getAttributeValue()
for consistency with Elements, _even_though_ an Attribute is always

I am one of those in the camp that believe a
getChildText(name,namespace) method should exist for all the reasons
that have been discussed by the proponents of this already.  It is a
common case and will make code more concise.

For some applications, order of elements DOES count (as was recently
pointed out by a list member).  Would it be possible to insert the new
Content being added into the returned List by getChildElements() using
list.add(idx,newthing) ?  If it doesn't work right now, I really think
that it would be useful to have the List be "backed" by JDom.  If you
ultimately decide against this proposal that the returned list should
not be backed by JDom, then it should definitely be made unmodifiable
since some clients may be confused and expect the DOM to actually be

Must addContent(xxxx) and removeContent(xxxx) both be overloaded by all
Node types?  Lets just say, for the sake of argument, that there is a
Node interface that simply flagged Element, Entity, etc. as being a
Node. (Maybe it should be called Content, anyways...).  Then, if you
wanted to enable the ability to add/remove an element at a certain
index, you would have addContent(idx,Node) and removeContent(idx,Node). 
All the instanceof's would only be around twice, once for each of
these.  addContent(Node) and removeContent(Node) would immediately call
their add/Remove(idx,Node) counterparts with a... lets say a
Integer.MAX_VALUE which signifies that it goes on the end.  Would this
be easier overall?  There would be fewer methods, and it wouldn't really
be a big deal doing the if-else instanceof section twice.

Just my 2 cents.

-- David Smiley

More information about the jdom-interest mailing list