Re: Is it possible to extend nsIDOMNode and alike?

On Apr 11, 6:22 pm, Jonas Sicking <[email protected]> wrote:
> [email protected] wrote:
> > I have Mozilla embedded in my application through Java-xpcom. I want
> > to attach certain reference (to Java object) to each of the nodes in
> > the DOM tree. In another word, once I get a nsIDOMNode from Mozilla, I
> > would like to call methods on its attached reference. I can certainly
> > build a map and store the references in it. But it won't scale well
> > and constantly adding/removing from a big map is kind of expensive.
> > Since nsIDOMNode is an interface, I am thinking if I can wrap
> > Mozilla's implementation in my own class and somehow provide that
> > class back to Mozilla DOM then I should be able to achieve what I
> > need. The problem now lies in how to provide the class back to
> > Mozilla. nsIDOMDOMImplementation looks like a potential entry point
> > but is read-only on nsIDOMDocument. Is the route I am taking even
> > possible in xpcom? Are there any other solutions that you can suggest?
> > Thanks in advance for your help.
>
> Passing back another object is unlikely going to work. The nodes in
> mozilla have to implement a large number of interfaces and you'd have to
> get them exactly right for all types of nodes for things to work properly.
>
> What you could do instead is to QueryInterface the node to nsINode and
> use the Get/Set/Delete/UnsetProperty API to store any additional
> information about the node that you need.
>
> Note though that behind the scene that is implemented using a hash
> table, so if you're worried about performance with that then this API
> isn't going to help you much.
>
> That said, hash tables generally scale really well. It shouldn't be any
> slower to use a hashtable with 1000 entries, than one with 2 (not
> entirely true, but sort of).
>
> / Jonas

Thanks Jonas. I think the QueryInterface route you suggested would
satisfy what I need. Just want to confirm that you meant nsIDOM3Node
which has that propety API. As I understand, this means one hashtable
per node. Is it correct? If so then there should be no performance
issue because I won't have that many properties per node. What I was
concerned previously was that I would have a hashtable with each of
the node as the key, so as the number of the node increased this
hashtable might have performance problems.

Feng