[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: DOM Confusion

• From: Ray <ray@g...>
• To: mcc@a... (Mike Champion)
• Date: Thu, 30 Apr 1998 08:28:56 -0600 (MDT)

> >My confusion comes from the fact that XMLNode doesn't inherit from
> >Node in the DOM spec. Thus, XMLNode doesn't have functions on
> >it like Node.getFirstChild(), or does it?
> 
> This was a typo (mine!).  XMLNode should have been defined to inherit from
> Node.  Sorry for all the confusion this has caused.

Thanks for the correction Mike. The typo also extends to the
Java language bindings on the W3C site (and also, I think both IBM 
XML4j and SAXDOM have this mistake too)

> >So why not dispense with XMLNode altogether and make the Node
> >interface implement these functions? Simply define that expandEntities
> >is "always true" for HTML documents, or some such.
> 
> Something like that is under consideration; I can't be more specific
> because the methods for doing this have not been nailed down yet.

 No problem. Too bad you guys don't have the luxury of using function
overloading. :)


> >3) extra nit: the function names are overly verbose and option #2
> >would solve it.
> Whimper .... the function names are verbose because of the astonishingly
> complex web of constraints that they must satisfy.  "Brevity" is actually
> one consideration, but less important than clarity, internal consistency,
> avoiding clashes with existing APIs in widespread use, compatibility with
> the name scoping scheme in ECMAScript .... etc.  

I realize that, and I'm glad you guys are taking that into
consideration.  One of the problems I had on my last project was that
I was using Lark, and I wanted to override the Element that Lark used
to build trees (I had my reasons for letting Lark build the tree,
relating to some third party code I had to interoperate with) with a
subclass that implemented swing.tree.TreeNode, however TreeNode
defines

public abstract Enumeration children()

but Lark's Element defines

public Vector children()

And as you know, you can't overload based on return types :(



In such cases, Java's inner classes yield a solution, which is to
use internal delegate classes

public class SuperNode implements TreeNode
{
  public Node getDOMNode() { ... }
  
  class DOMAdapter implements Node { .... }
}



-Ray

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Follow-Ups:
  • Re: DOM Confusion
    • From: Mike Champion <mcc@a...>

• References:
  • Re: DOM Confusion
    • From: Mike Champion <mcc@a...>

• Prev by Date: Re: DOM Confusion
• Next by Date: Re: DOM Confusion
• Previous by thread: Re: DOM Confusion
• Next by thread: Re: DOM Confusion
• Index(es):
  • Date
  • Thread