[jdom-interest] Element Reference from Attribute

[James Strachan]

----- Original Message -----
From: "Amy Lewis" <amyzing at talsever.com>
> My job demands an enormous amount of navigability, and I'd really like
> to use something less awkward and by-committee than DOM.  In my
> context, though, the best I can manage is to mutter, "well, JDOM isn't
> any *worse* than DOM, and it might get better."  But I don't see the
> API moving that direction; Bob seems a relatively lonely voice here.
> *shrug*  Time to try something else, perhaps.

I hear the voice of the navigators ;-)

One of the most difficult things to get right in the XML framework /
interface world is that XML has so many diverse uses that keeping everyone
happy is very difficult.

I agree with many of the sentiments Jason and others have made that the core
of JDOM should be as small and efficient as possible. The standard JDOM API
org.jdom.* is pretty good attempt at a base level JDOM functionality.
Anything more complex should be done with custom builders and custom
derivations of Element, Attribute etc.

So I'd propose building a small collection of derivations of Element,
Attribute et al which support all of the complex navigations that you and
bob need in the XPath world. Then we can have a standard builder (e.g.
XPathSAXFactory) to build a tree of Element / Attribute implementations that
you need.

e.g.

package org.jdom.xpath;

import org.jdom.*;

public class XPathAttribute extends Attribute {

    // all the various extra navigation methods...
    public Element getParent() {
        ..
    }
}

Admittedly, you'd have to cast a little bit to use your new highly navigable
XPathElement / XPathAttribute objects but that would be an acceptable
trade-off wouldn't it?

J.

James Strachan
=============
email: james at metastuff.com
web: http://www.metastuff.com



If you are not the addressee of this confidential e-mail and any
attachments, please delete it and inform the sender; unauthorised
redistribution or publication is prohibited. Views expressed are those of
the author and do not necessarily represent those of Citria Limited.