Re: Is it possible to extend nsIDOMNode and alike?

On Apr 14, 7:54 pm, Jonas Sicking <jo... <at> sicking.cc> wrote:
> fch... <at> gmail.com wrote:
> > On Apr 11, 6:22 pm, Jonas Sicking <jo... <at> sicking.cc> wrote:
> >> fch... <at> gmail.com 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.
>
> No, I did in fact mean nsINode. The problem with using nsIDOM3Node is
> that the properties you set would be exposed to web content. I.e. a web
> page would be able to get to the data you stick in there, or you could
> potentially even be overwriting data that the web page had stored.
>
> Using nsINode you can use a category which would store the data in a
> place where it's separate from the data stored by the web page.
>
> We don't use a hash table per node no, we currently use one per
> document. However the performance characteristics for a hash table is
> such that that should not be significantly slower just because you store
> more stuff in it.
>
> Have you tested to make sure that a single hash table is too slow for
> your means?
>
> / Jonas

I couldn't find nsINode in Java xpcom API. Is it exposed at all? I
tried setUserData and getUserData on Level 3 DOM API and it seemed to
work ok. I also tried to read it from web (getAttribute on the
element) and what I got back was null. Can you clarify a little bit
how the data set in nsIDOM3Node this way is exposed to web content?
Thanks a lot.

Feng