[jdom-interest] Re: Subclassing Element vs Element Context

Joseph Bowbeer jozart at csi.com
Sat Nov 4 18:19:15 PST 2000


Adding a userObject can accomplish a lot without forcing the user to
subclass or to provide an external mapping.

I've used userObjects in Swing and X.  They're not elegant, but they're
easy to use and they avoid the fragile subclass problem.


A related enhancement that I've suggested before, but for which I
personally do not have a use (yet), is to make the JDOM classes
Visitable.

Making all the JDOM classes implement Visitable and providing a Visitor
baseclass for the users to extend would give users a mechanism for
implementing custom traversals, as well as a mechanism for attaching
additional behavior to the JDOM classes.

I'm refering to the Visitor pattern by the Gang Of Four.  There's a good
description plus links to more resources here:

    http://www.ootips.org/visitor-pattern.html


Does anyone currently have a need for this?


Details:

Given a Visitable interface defined by JDOM:

    interface Visitable {
        void accept(Visitor visitor);
    }

Each concrete object in a document would implement Visitable, for
example:

    class Element implements Visitable {
        // ...
        public void accept(Visitor visitor) {
            visitor.visitElement(this);
        }
    }

JDOM would also define an abstract base class for visitors:

    abstract class Visitor {
        public void visitDocument(Document document);
        public void visitElement(Element element);
        public void visitAttribute(Attribute attribute);
        // ...
    }


----- original message -----

Dave Churchville dmc at clearlight.com
Sat, 04 Nov 2000 16:16:00 -0800

Jehoiada Bernard wrote:

> For applications that navigate the document as a
> simple tree of Elements, how about simply being
> able to attach contextual information to an element?
> e.g., element.setContext(Object);  You could then
> color the tree with any information you wish
> without subclassing Element. This seems like
> a low impact change to the current design.
>

I somewhat agree with this, this is like Swing's "setUserObject()" on
TreeNodes.  That would be pretty useful and its not as controversial as
the other proposed enhancements to JDOM.

Its not *quite* as nice, though, as knowing the object you are dealing
with, since typical code would say:

Element myElement = rootElement.getChild("foo");
MyCustomObject o = (MyCustomObject) myElement.getUserObject();
o.setVisited( true);

instead of:

MyCustomElement e = (MyCustomElement) rootElement.getChild("foo");
e.setVisited(true);

But frankly, your approach does solve the problem, and it does so
without any significant impact that I can think of.

--Dave






More information about the jdom-interest mailing list