[jdom-interest] Re: Radical Suggestion

[Bradley S. Huffman]

Dennis Sosnoski writes:

> That's great to find out about - I was thinking of suggesting null as a 
> wildcard for namespace, but didn't realize it was already being done. 
> The behavior should definitely be documented in the javadocs, though - 
> otherwise some people may consider it a bug and "fix" it. :-)

Maybe not a bug, but it isn't consistent with other parts of the
Element API, specifically the constructor Element(String, Namespace)
and the method setNamespace(Namespace)) which both define a null to
mean Namespace.NO_NAMESPACE.

The behavior of getChild(ren) comes from their use of ElementFilter which
defines null to be *any* namespace.  Personally I consider that a "oops"
that should be "fixed" to mean no namespace :-)

I agree with ERH, I think operating on local name only is a very, very bad
habit that will eventually bite the developer in the butt and should not be
encouraged in the core API.  But if someone really wants to do it, a Filter
would do the job easily.  Come to think about it, a protected method in
ElementFilter, say matchNamespace, to encapsulate the namespace check would
be a good idea.  Then developers could very easily subclass and change the
behavior for those rare cases where the default won't work for their
particular needs.

BTW, ElementFilter checks the namespace URI only, not the prefix and URI. This
means for two Elements (e1,e2) returned by getChildren:

    e1.getNamespace().getURI() == e2.getNamespace().getURI()

but doesn't necessarily mean

    e1.getNamespace() == e2.getNamespace()

or either one is == to the Namespace passed to getChildren.  Normally this
is what you want, but it might be confusing to new users and should be
documented better.

Brad