[jdom-interest] The JDOM Model
Hallvard Trætteberg
hal at idi.ntnu.no
Mon May 6 10:26:00 PDT 2002
RE: [doom-interest] The JDOM Model, Chapter 15 of Processing XML with
Java-----Original Message-----
> 1. What is a node?
I don't know. I do know it has one parent, and zero to N children,
though. So how about an interface to describe it. Then all the concrete
classes we like so much can implement it as best fits their specific tasks.
public interface Node{
public Node [] children = get Children(); // * more later....
public Node parent = get Parent();
}
Another way of thinking of interfaces is that it defines the set of methods
that are needed for a general machinery to do interesting things. This is
the way I think of the xxxModel interfaces in Swing: The define the methods
I need to implement to make a custom class viewable through a Jxxx.
For JDOM nodes, the interesting operations are adding them, moving them
around, deleting them and externalising them. With methods for each of
these, it should be possible to make a custom class that may be inserted in
a JDOM tree, and that will be written out as valid XML. It does not bother
me that it will not be reconstructed as this custom node, as long as I can
replace the corresponding nodes with my custom node after the JDOM tree has
been built.
A public interface for these operations will include:
public interface Node {
public List getChildren(); // return a list of children
public boolean addChild(Node child); // return false if invalid to add
child
public boolean removeChild(Node child); // return false if child is not
a child of this node
public boolean validate(); // 'global' check of sub-tree
public void output(SAXHandler handler); // generate SAX events for this
node
}
The most interesting method is the last one, which makes it possible to
drive SAX filters and transformations. An alternative to returning a List
would be to include int getLength() and Node getChild() methods, and perhaps
an Iterator getChildren() method.
It might be that we would end up with DOM if we continue this process, but
for new-comers like me it is interesting to understand what is required of
such an interface for different purposes.
This is one of the two major complaints I have about JDOM. Lack of
common interfaces. I think fixing it requires two things. A clear
specification of what those interfaces should be, and a major refactoring of
the code base to implement the specification.
If we could agree on a set of criteria for measuring the "goodness" of the
refactored code base, we could make a contest of the "best" node interface
definition :-)
Hallvard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20020506/49213e72/attachment.htm
More information about the jdom-interest
mailing list