[jdom-interest] Element Reference from Attribute

Amy Lewis amyzing at talsever.com
Fri Nov 17 15:51:30 PST 2000


On Fri, Nov 17, 2000 at 09:03:56AM -0800, Patrick Dowler wrote:
>On Fri, 17 Nov 2000, you wrote:
>> > I guess I missed something early in this discussion, so this is probably a
>> > dumb question. At what point in your code do you have a reference to 
>> > an Attribute that you didn't get via
>> > 
>> > 	Attribute a = e.getAttribute(key);
>> > 
>> > That is, how is it that one can be navigating from an Attribute with no
>> > knowledge of the Element with said Attribute?
>> 
>> Using my XPath library, for one.
>> 
[snip]
>> You're now holding a list of Attributes named 'goober', with no
>> convenient way to find the parent.  (Which also means I can't implement
>> easily the XPath of "/foo/bar/baz/@goober/..", which would automagically
>> return the parents of all 'goober' attributes).
>
>Aahh... Here you do want the Elements with "goober"s. When you say you 
>cannot implement it, you are saying you can't implement it on top of 
>XPath("/foo/bar/baz/@goober") - ie. get the attributes and then traverse - but 
>you could implement it directly since you can keep both the Element and 
>Attribute references handy while traversing... yes? namely,
>
>	Element e = ...
>	Attribute a = e.getAttribute("goober");
>	if (a != null )
>		addToList(e);
>
>The question still reduces to "do we ever have only an Attribute reference
>and want the Element?" 

Yes.  Bob gave a simple example.  Try something like
/descendant::foo/bar/@goober[../@gomer]  More examples can be
multiplied (and in case you're wondering, the inability to navigate
effectively is my chief complaint with JDOM ... I'm aware that others
don't need anything more complex than getChild().getAttribute(), but my
work demands something less distressingly limited in order to be
maintainable).  Suppose I want to process all of the attributes (there
may be a hundred) of a particular type in a document, uniformly. 
Suppose I want to check their parents as well, since I *might* want to
process them (depending on type and content), and for certain
type/content combinations, I want to pick up a node in a certain
location and use its value to drive additional processing.

I *could* iterate over all the children of the root, and their
children, and so on, tediously, keeping track of any node that I
*might* later be interested in, in case it turns out that there's a
node in a given relationship (but I haven't iterated to there yet) that
has the characteristics that will make me want to process this node I'm
saving.  Can you say "oh, yuck"?

Even within the admittedly limited APIs for navigation in JDOM, I have
to be careful to keep not only the list of Attributes
(element.getAttributes()) that I want to reference for some reason, but
if I may pick up another list, then I better keep a reference to the
parent too.  Tfu.  I add an attribute to an element, and it promptly
forgets who its parent is; I have to keep track, even though this is
a tree and the single piece of information I'm most interested in is
the attribute (I could keep the element, then keep calling
element.getAttribute() whenever I need it ... perfectly elegant and
attractive (in BASIC, perhaps)).

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.

Amy!



More information about the jdom-interest mailing list