[jdom-interest] Element Reference from Attribute
jhunter at collab.net
Sun Nov 19 10:10:25 PST 2000
> 1. Everything needs to know its parent. I don't really care if that
> adds 4 bytes to each object.
This would make moving objects more consistent as well, since it would
be easy to detect if the same object existed at two points in a tree and
disallow that add. The downsides I see are 4 extra bytes per object,
and extra processing to manage parents.
Can you give the XInclude use case for where knowing the parent helps?
> 2. Using Strings instead of a Text class is extremely inconvenient.
With a design so that getMixedContent() returned a list including node
of type Text but getText(), or some such method, still returned a
String? It's a hard requirement that you can get a String from an
Is the use case here the knowledge of parent issue?
> 3. A Node interface or superclass would be a good thing.
Could you provide more detail about how you would design it?
> However, there are still some aspects of JDOM that have proven to be
> useful or at least convenient in working with XInclude:
> 1. Classes instead of interfaces
I agree, the list of reasons classes are better keep growing.
> 2. Constructors instead of factories
> 3. Following Java coding conventions
> 4. Nodes that don't belong to any document are very useful.
Agreed. And only possible due to #1. I'm curious, why has this been
handy for an XInclude processor?
> On an unrelated note, I've also come to the conclusion that Java does
> need friend functions. There are a lot of cases where the
> org.jdom.input package and prg.jdom.output package classes have
> legitimate reasons to know more about the objects in org.jdom than
> are exposed through the public interface, but I'm not sure there's
> anything we can do to fix that. (Does anyone know a good design
> pattern that substitutes for friend functions?)
I agree. An org.jdom.translate package for XSLT might need special
rights as well.
More information about the jdom-interest